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[57] ABSTRACT 

Improved apparatus for specifying and resolving ad- 
dresses of operands in a digital data processing system. 
Instructions executed by the system are contained in 
procedures. Addresses are calculated using a set of 
architectural base addresses. Operands are represented 
in the instructions by means of names. The names in- 
clude immediate names, which directly specify one of 
the architectural base registers and a displacement, and 
table names, which specify a name table entry in a name 
table associated with the procedure. The name table 
entry specifies how the address of the operand repre- 
sented by the table name may be derived using the 
architectural base addresses and information contained 
in the name table. Each name table entry includes a 
basic name table entry. The basic name table entry con- 
tains a base source specifier and a base or displacement 
specifier. The base source specifier specifies either one 
of the architectural base addresses as a base address or 
that the base address is not one of the architectural base 
addresses. In the former case, the base or displacement 
specifier specifies a displacement; in the latter, it con- 
tains an immediate name or a table name specifying 
another name table entry in the name table and the base 
address is derived using the immediate name or table 
name. Calculation of addresses is performed by name 
processing apparatus which is responsive to the base 
source specifier and the base or displacement specifier. 
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APPARATUS FOR SPECIFYING AND RESOLVING 
ADDRESSES OF OPERANDS IN A DIGITAL DATA 
PROCESSING SYSTEM 

5 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

The present patent application is related to U.S. pa- 
tent application Ser. No. 266,539, filed May 22, 1981, 
and to U.S. patent application Ser. Nos. 301,997, 10 
301,999, 302,000, 302,261, 302,262, 302,263, 302,264, 
302,321, and 302,322, all filed on Sept. 11, 1981, and 
U.S. Pat. Ser. No. 303,312, filed Sept. 15, 1981. 

BACKGROUND OF THE INVENTION 15 

1. Field of the Invention 

The present invention relates to digital data process- 
ing systems and more particularly to digital data pro- 
cessing systems characterized by one or more of the 
following features: 20 

An address space segmented into objects, so that an 
address of data consists of two parts: an object 
identifier specifying an object and an offset value 
specifying a location within the object specified by 
the object identifier. 25 

Pointers, that is, data which represents addresses, 
which may represent addresses either directly indi- 
rectly. Pointers which represent addresses directly 
contain addresses; those which represent addresses 
indirectly contain information which the digital 30 
data processing system uses to obtain an address. 
Multiple S-languages instead of a single instruction 
set. An S-language is an intermediate language 
closely related to a high-level programming lan- 
guage. The meaning of a given operation code in a 35 
system with multiple S-languages depends solely 
on the S-language. 

Standard operation code sizes and operand syllable 
sizes for all S-languages. 

Instructions contained in procedures in special ob- 40 
jects called procedure objects. Execution of a pro- 
cedure may be commenced only by a Call instruc- 
tion. 

Instructions which specify locations in memory for 
data, an operation to be performed on the data, and 45 
a destination location in memory for the result of 
the operations, as opposed to instructions which 
specify transfers between memory and registers 
and operations on the contents of the registers. 

Call and Return instructions which have the same 50 
semantics and manipulate the same data structures 
in all S-languages. 

Base-displacement addressing from base pointers 
whose values may be changed solely by the execu- 
tion of Call and Return instructions. 55 

Instructions in which operands are represented by 
names, that is, indexes into data structures called 
name tables containing name table entries. In order 
to obtain the operand’s location, the name is re- 
solved, i.e., information in the name’s name table 60 
entry is combined with the values of the base point- 
ers to produce a descriptor specifying the location, 
length, and type of the operand represented by the 
name. 

Cache means in the central processing unit for en- 
caching information required to resolve a name. 

The present invention may be employed with advan- 
tage in any digital data processing system having one or 
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more of the listed characteristics and is particularly 
advantageous in a digital data processing system having 
several or all of the above characteristics. 

2. Description of the Prior Art 

The present data processing systems are an improve- 
ment over certain previous digital data processing sys- 
tems, hereafter referred to as the original data process- 
ing systems and described more fully in U.S. patent 
application Ser. No. 266,539, filed May 22, 1981. The 
present and original systems have the characteristics 
listed above and have a number of advantages over 
traditional digital data processing systems. 

Considering first the characteristics shared by the 
original and present systems, the segmentation of the 
address space into objects permits an address space 
which is on the one hand very large, and on the other 
hand divisible into private address spaces. Which users 
have access to a given set of objects is determined by a 
component of the digital data processing system called 
the access control system. 

With regard to the pointers, the existence of pointers 
which represent addresses either directly or indirectly 
allows the interpretation of a pointer which represents 
an address indirectly to be delayed until the actual exe- 
cution of the program using the pointer. Indeed, though 
the value of the pointer remains unchanged, the address 
derived from the value may vary in different executions 
of the program. 

With regard to multiple S-languages, the use of differ- 
ent S-languages corresponding to different high-level 
languages allows the S-language to be tailored to the 
high-level language, thereby simplifying the task of 
compilers and reducing the amount of S-language code 
produced from a given amount of high-level language 
code. The complexity of S-language code is further 
reduced by the use of call and return instructions and 
instructions which specify operations in terms of the 
location of data in memory and the operations to be 
performed on the data and by the use of names to repre- 
sent operands in the instructions. Since the names refer 
to name table entries containing location, length, and 
type information, complicated references are possible in 
spite of the simplicity of the names. The use of standard 
sizes for operation codes and operand syllables in all of 
the S-languages, finally, allows the construction of spe- 
cialized hardware devices for parsing instructions. 

The combination of uniform call and return S-instruc- 
tions with base-displacement addressing from base 
pointers whose values may be changed only by a call or 
a return S-instruction, finally, ensures that a program’s 
addressing environment remains constant throughout 
the execution of a procedure and allows name table 
entries to specify locations as offsets from the base 
pointers. 

Experience with the original digital data processing 
systems of the type described above has, however, re- 
vealed a number of problems and shortcomings which 
reduce the speed and efficiency of execution of pro- 
grams executed on such systems. These problems and 
shortcomings involve pointers, names and name table 
entries, the form of the S-language instructions, the 
kinds of operations which an opcode in an S-language 
may specify, the call and return operations, and the 
resolution of names in a procedure specifying the argu- 
ments with which the procedure was invoked. 

Beginning with problems associated with object ad- 
dressing, a pointer which directly specifies an address 
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must specify both an object identifier and an offset, and results in three kinds of inefficiencies: first, additional 

pointers must therefore contain a large number of bits. memory operations are required to store the result of 

Operations involving large pointers are therefore ex- the first operation and fetch it for use in the second 

pensive both in terms of fetching and storing the point- operation. Second, additional operand syllables are 

ers and in terms of processing them. While the extra 5 required to specify the location at which the result of 
overhead involved in these operations is not important the first operation is to be stored and from which it is to 

in the infrequent cases in which a pointer specifies an be retrieved, and third, additional memory is required 

address indirectly or specifies a location in another for the temporary storage of the result of the first opera- 

object, it interferes markedly with speed and efficiency tion. 

in the frequent cases in which the pointer simply sped- 10 Similarly, the use of a single Call instruction requires 
fies another address in the object which contains the the inefficient treatment of certain simple cases. At its 

pointer. Indeed, in these cases, the only relevant infor- simplest, a call operation in the original systems requires 

mation in the pointer is the offset, since the object iden- only the following: 

tifier required for the pointer’s value may be obtained Saving FP, a base pointer specifying the calling pro- 
from the pointer’s own address. 15 cedure s stack frame, SP, a pointer to the top of the 

The problems associated with names are similar to calling procedure s stack frame, and the calling 

those associated with pointers. While a name and its procedure’s program counter value, 

associated name table entry offers a powerful means for Calculating a new value for the program counter, 
dealing with complex references, no name can be re- Constructing a new frame on the stack for the called 
solved without reference to a name table entry and the 20 procedure and calculating new values for FP and 
need to retrieve information from a name table entry SP. 

markedly increases the number of memory references A return operation need only restore the saved values of 

needed to execute a program. The problems are in- the program counter, FP, and SP. Other calls, however, 

creased by the fact that a large number of programs do require the retention of much more state. Examples in 

not form complex references and therefore do not need 25 order of increasing complexity are calls to procedures 
the power provided by the use of names and name table using different name tables, calls to procedures using 

entires. Furthermore, the arrangement of the informa- different S-languages, calls to procedures contained in 

tion in the name table entry is crucial in a digital data different procedure objects, and calls which affect the 

system using names, since the length of time required to access control system. Returns from such calls must of 

resolve a name is dependent on the number of fetches 30 course restore the retained state. In the original systems, 

from memory required to obtain the information in the all Calls and Returns commence as if they are one of the 

name’s name table entry. complex cases and do more than is required for the 

The problems associated with the S-languages stem simplest case. Since simple Calls and Returns occur 
from two main sources: first, the physical form of the with higher frequency than the others, the result is 
S languages is still too complicated to allow the con- 35 again slow and inefficient execution of programs, 
struction of low-cost and efficient hardware parsing The fact that names in the original system are nothing 

devices and second, the simplicity of the operations more than indexes of name table entries also prevents 

described by the S languages make it difficult to sepa- maximum use of encachement means for descriptors, 

rate certain special types of operations capable of par- Many names in a procedure’s S-instructions refer to 

ticularly efficient treatment from other operations capa- 40 arguments to the procedure, and these names are re- 

ble of less efficient treatment. solved by forming a descriptor from a pointer to the 

In the original systems, the S-languages have opera- argument’s location. The pointer to the argument s 

tion codes of a fixed size, but the operand syllables in a location must be formed when a call is made and as a 

given procedure may have one of a number of sizes. linkage pointer, its value will not change dunng the 

Thus, the hardware parsing device must cope with 45 execution of the called procedure. The pointer is there- 

opcodes and operand syllables which differ in size and fore encacheable and the descriptor corresponding to it 

with a number of different sizes of operand syllables. is available for encachement when the Call S-instruc- 

Furthermore, it may be necessary to reset the hardware tion is executed, but in the original systems, there is no 

parsing device when a call or return instruction is exe- way of determining when the call is made what names 

cuted, and it is therefore necessary to save the size of 50 the called procedure will refer to the pointers by. Con- 

the operand syllables in the calling procedure. sequently, the pointers cannot be encached when the 

As described above, S-instructions in the original call is made, but must be encached when a name whose 

systems specify operations in terms of an operation, resolution requires the value is presented to the name 

locations in memory containing operands for the opera- cache and the value is not present, 

tion and a location for the result of the operation. In 55 The present invention provides data processing sys- 
certain frequent cases, in which the result of a first tern improvements and features which solve the above- 
operation is used immediately as an operand in a second described problems and limitations of the original sys- 

operation, it is more efficient to keep the result of the terns. 

first operation in the central processing unit, without SUMMARY OF THE INVENTION 

storing it in memory and retrieving it for the second 60 ... . 

operation. S-instructions in the original systems have no The present invention relates to means for increasing 
means of specifying that a result be retained in the cen- the efficiency of operation of the original digital data 

tral processing unit or that a succeeding S-instruction processing systems while retaining the original systems 

use the retained result as an operand. Consequently, the capabilities. The original digital data processing systems 

S-instruction for the first operation must specify that the 65 have shown themselves more powerful than traditional 
result be stored at some location in memory and the digital data processing systems with regard to certain 

S-instruction for the second operation must specify that operations which are difficult or impossible on these 

location as the location of one of the operands. This traditional systems, but have also shown themselves to 
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be less efficient than traditional digital data processing 
systems with regard to certain frequently-occurring 
simple operations. By providing means for distinguish- 
ing these frequently-occurring operations from those 
requiring the full power of the original systems, the 
present invention allows the construction of digital data 
processing systems which retain the full capabilities of 
the original digital data processing systems and also 
attain or exceed the efficiency of traditional digital data 
processing systems. 

The problems with names are solved in the present 
invention by creating two classes of names, table names, 
which work in the same manner as names in the prior 
art, and immediate names, which contain in themselves 
all the information needed for a simple data reference. 
Immediate names therefore need no name table entries 
and may may be resolved without reference to the name 
table. In many programs, most of the names are immedi- 
ate names. In such programs, the amount of information 
which must be fetched from the name table is greatly 
reduced and the speed of program execution is corre- 
spondingly increased. A further benefit of immediate 
names is a reduction in the size of the name table. In the 
present invention, the name table entries themselves 
have been improved to reduce the number of bits which 
must be fetched to resolve a table name and to speed the 
operations performed in the course of the resolution of 
a table name. The improved name table entries consist 
at least of a basic name table entry and may also include 
up to three suffixes. The basic name table entry includes 
an architectural base pointer code and a base or dis- 
placement field. The architectural base pointer code 
either specifies one of the architectural base pointers as 
a base address or that the base address is not an architec- 
tural base pointer. When one of the architectural base 
pointers is the base address, the base or displacement 
field provides the displacement; otherwise, the base or 
displacement field specifies the base address. When the 
base or displacement field specifies the base address, it 
does so by means of either a table name or an immediate 
name. The table name or immediate name is resolved 
using the name table and the architerctural base pointers 
to obtain the base address. 

BRIEF DESCRIPTION OF DRAWINGS 
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FIG. 10 is a diagram of the procedure object of the 
present invention. 

FIG. 11 is a diagram of entry descriptors and proce- 
dure environment descriptors of the present invention. 
5 FIG. 12 is a diagram of macrostack frames in the 
present invention. 

FIG. 13 is a conceptual diagram of linkage pointer 
encachement in the present invention. 

10 DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

Introduction 

The inventions disclosed herein were made in the 
15 course of continuing development of the original data 
processing systems described in U.S. patent application 
Ser. No. 266,539 and related patent applications and 
may be best understood in the light of U.S. patent appli- 
cation Ser. No. 266,539. U.S. patent application Ser. 
20 No. 266,539 is accordingly incorporated by reference 
into the present application and is referred to through- 
out the present application. In particular, reference 
numbers having five digits in the present application 
refer to figures from U.S. patent application Ser. No. 
25 patent application 266,539, while those having three or 
four digits refer to figures in the present application. In 
both sets of figures, the rightmost two digits indicate 
items in the figure whose number is specified by the 
leftmost digits. Thus, 201 is a reference number specify- 
30 ing FIG. 2 of the present application, while 46865 is a 
reference number specifying FIG. 468 of U.S. patent 
application Ser. No. 266,539. Certain reference numbers 
in U.S. patent application Ser. No. 266,539 have three 
or four digits. To distinguish these reference numbers 
from those referring to figures of the present applica- 
tion, the present application expands the former refer- 
ence numbers to five digits by adding leading 0’s. For 
example, reference number 602 of U.S. patent applica- 
tion Ser. No. 266,539 appears herein as reference num- 
ber 00602, specifying FIG. 6 of U.S. patent application 
Ser. No. 266,539. 

The digital data processing system (CS 10110 ) of U.S. 
patent application Ser. No. 266,539 was described in 
45 U.S. patent application Ser. No. 266,539 as a system 
including hardware and a micromachine, described in 



FIG. 1 is a diagram of the improved pointer formats 
of the present invention; 

FIG. 2 is a diagram of the improved names of the 
present invention; 

FIG. 3 is a diagram illustrating the resolution of table 
names and immediate names in the present invention. 

FIG. 4 is a diagram providing an overview of the 
improved name table of the present invention. 

FIG. 5 is a detailed diagram of the improved name 
table entries of the present invention. 

FIG. 6 is a diagram of a typical S-instruction, the 
name table entries for its names, and the stack frame for 



Chapter 2 of U.S. patent application Ser. No. 266,539, 
an S-interpreter for interpreting S-instructions (SINs), 
described in Chapter 3 of U.S. patent application Ser. 
No. 266,539, and KOS procedures and microcode for 
providing object addressing, control of access to ob- 
jects, and processes for executing procedures, all de- 
scribed in Chapter 4 of U.S. patent application Ser. No. 
266,539. The inventions described in the present appli- 
cation concern only the S-interpreter portion of CS 
10110. The other portions of CS 10110 remain as de- 
scribed in U.S. patent application Ser. No. 266,539. In 
particular, the embodiment of the inventions described 



the procedure containing the S-instruction in the pres- 
ent invention. 

FIG. 7 is a diagram of the improved instruction 
stream of the present invention. 

FIG. 8 is a conceptual diagram of the S-language 
machine in CS 101 10 of the original digital data process- 
ing system. 

FIG. 9 is a conceptual diagram of the Calculating 
Unit and Accumulator in the improved S-language 
machine of the present invention. 



in the present application employs the hardware of CS 
10110; the hardware is made to perform the new func- 
tions described in the present application by means of 
microcode specific to this embodiment. The new micro- 
code is included in Appendix A of the present applica- 
tion. As may be seen in the ensuing discussions, other 
embodiments of the inventions may employ different 
hardware means. 

The inventions described in the present application 
concern 6 different parts of the S-interpreter portion of 
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the digital data processing system described in U.S. 
patent application Ser. No. 266,539: 

A. Pointers: Pointers in the present invention have 
two main format types: a 32-bit short format for 
resolved object-relative pointers and a 128-bit long 
format for all other kinds of pointers. 

B. Namespace: Namespace in the present invention 
now resolves two kinds of Names: Table Names, 
corresponding to the Names of CS 10110, and im- 
mediate Names, which may be received without 
reference to a Name Table. 

C. The Instruction Stream: All syllables in the In- 
struction Stream of the present invention are 16- 
bits long. SOPs now include an 8-bit Opcode Modi- 
fier Field as well as an 8-bit Opcode. 

D. Accumulator SOPs: The present invention in- 
cludes an Accumulator which receives the result 
on every operation involving EU 10122 and which 
SOPs may specify as a source of data for an opera- 
tion. 

E. General Call, Neighborhood Call, and common 
Return: The present invention includes General 
Call SINs for Calls between Procedures which do 
not share Procedure Environment Descriptors 
(PEDs) and Neighborhood Call SINs for Calls 
between Procedures which do share PEDs. The 
MAS Stack Frame produced by a General Call 
SIN is an expanded version of the MAS Stack 
Frame produced by a Neighborhood Call SIN, and 
the common Return SIN reads flags in the MAS 
Stack Frame to determine which kind of Call cre- 
ated the MAS Stack Frame and what actions are 
necessary on return. 

F. Linkage Pointer Encachement: Pointer values 
located at negative offsets from SDP and FP may 
be encached and may be accessed in the cache by 
means of Immediate Names. 

The parts are described in the order listed above. 

A. Pointers 

A pointer is a data item which represents an address. 
In U.S. patent application Ser. No. 266,539 filed May 
22, 1981, pointers in CS 101 10 are described in Part A of 
Chapter 3. The following discussion begins with a short 
summary of pointers in CS 10110 and then presents 
pointers in the present invention. 

1. Pointers in CS 10110 

In CS 101 10, pointers represent UID-offset addresses. 
They may do so in two ways; by specifying the UID- 
offset address they represent directly, or by specifying 
values which identify information from which the UID- 
offset address represented by the pointer may be de- 
rived by user Procedures 00602 executing on CS 10110. 
Pointers which specify a UID-offset address directly 
are termed resolved pointers, and those which do not 
are termed unresolved pointers. In an unresolved 
pointer, the information from which the UID-offset 
address represented by the pointer may be derived may 
be represented in many different ways. For example, the 
information may be a UID and offset which is the ad- 
dress of the information required to derive the UID- 
offset address represented by the pointer, or it may be a 
value which serves as a key to locate the information in 
a hash table. Certain unresolved pointers are associative 
pointers. The UID offset address represented by an 
associative pointer may be derived and then placed in a 
table called the Associated Address Table (AAT) 30201 
accessible to microcode executing on FU 10120, thus 
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accelerating subsequent derivations of the UID-offset 
address represented by the associative pointer. 

The operation of deriving a UID-offset address from 
an unresolved pointer is called resolving the pointer. 

5 The operation begins when microcode executing on FU 
10120 detects an unresolved pointer. If the unresolved 
pointer is not an associative pointer, the microcode 
performs a microcode-to-software Call to a Procedure 
00602 which derives the UID-offset address repre- 
10 sented by the unresolved pointer and returns it to the 
microcode; if the unresolved pointer is an associative 
pointer, the microcode first attempts to lock up the 
UID-offset address represented by the associative 
pointer in AAT 30201; if the UID-offset address is not 
15 present, it then performs a microcode-to-software Call 
to a Procedure 00602 which derives the UID-offset 
address represented by the associative pointer and 
places it in AAT 30201; on return from the Call, the 
microcode again looks up the associative pointer in 
20 AAT 30201. Pointer resolution is described in detail in 
Section 3.A.C in U.S. patent application Ser. No. 
266,539. 

If a resolved or unresolved pointer is located in the 
same object as that specified by the UID-offset address 
25 the pointer represents, the UID specifying the pointer’s 
location and the UID for the address represented by the 
pointer are the same, and the pointer can represent the 
UID by means of a flag indicating that the pointer is in 
the same object as the address it represents. Such point- 
30 ers are termed object-relative pointers. 

In CS 10110, the type of a pointer is determined from 
its format. FIG. 301 of U.S. patent application Ser. No. 
266,539 presents the formats of pointers in CS 10110. 
Pointers in CS 10110 are 128 bits long and have three 
35 main divisions: a 32-bit Offset Field 30103, a 16-bit Flags 
and Format Field 30105, and an 80-bit UID Field 30115. 
In resolved pointers, Offset Field 30103 contains the 
offset of the UID-offset address represented by the 
pointer. In unresolved pointers, Offset Field 30103 is 
40 simply part of the value which identifies the information 
from which the UID-offset address represented by the 
pointer may be derived. 

Flags and Format Field 30105 is the means by which 
FU 10120 microcode determines what kind of pointer it 
45 is dealing with. The value of NR 30109 indicates 
whether a pointer is resolved or unresolved, and the 
value of Format Code 30113 indicates whether the 
pointer is an object-relative pointer and whether an 
unresolved pointer is an ordinary unresolved pointer or 
50 an associative pointer. The meaning of UID Field 
30115, finally, depends on the kind of pointer. In object- 
relative resolved pointers, UID Field 30115 is meaning- 
less; in UID resolved pointers, UID Field 30115 con- 
tains the UID of the UID-offset address represented by 
55 the pointer. In unresolved pointers, UID Field 30115, 
like Offset Field 30103, contains information from 
which the UID-offset address represented by the 
pointer may be derived. 

As explained in detail in Introductory Overview. B.l 
60 and 2.F.b.2.d.d. of U.S. patent application Ser. No. 
266,539, the UID-offset addresses represented by point- 
ers cannot be used directly inside FU 10120, but must 
instead be converted to Logical Descriptors 27116 in 
which the address specified by Logical Descriptor 
65 27116’s AON Field 27111 and OFF Field 27113 corre- 
spond to the UID-offset address specified by the 
pointer. Consequently, when FU 10120 obtains the 
UID-offset address of a data item from a pointer, micro- 
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code must first resolve the pointer as described above, if 
the pointer is unresolved, and then convert the UID- 
offset address represented by the pointer to its corre- 
sponding AON-offset address. Similarly, when a re- 
solved pointer value is stored in MEM 10112, micro- 5 
code must convert the address to be stored from the 
AON-offset form it has in FU 10120 to the UID-offset 
form it has in MEM 10112. The conversion from UID- 
offset address to AON-offset address is termed pointer- 
to-descriptor conversion, and the inverse conversion is 10 
termed descriptor-to-pointer conversion. The manner 
in which these operations are performed in CS 10110 is 
described in detail in Section 3.A.d of U.S. patent appli- 
cation Ser. No. 266,539. 

2. Improved Pointers 15 

The present invention provides improvements in 
pointers and pointer operations, retaining the kinds of 
pointers used in CS 11010 and providing new formats in 
order to facilitate descriptor-to-pointer conversion and 
pointer-to-descriptor conversion. The present invention 20 
thereby increases the speed of execution of programs. 

FIG. 1 is a representation of pointer formats in the 
present invention. There are two basic pointer formats: 
Short Pointer Format 101 and Long Pointer Format 
117. Short Pointer Format 101 is used for resolved 25 
object-relative pointers. Short Pointer Format 101 is 32 
bits long and has two fields: the left most bit is Format 
Specifier Field 103, and the remaining 31 bits are Offset 
Field 105. The value of Format Specifier Field 103 
indicates whether a pointer has Short Pointer Format 30 
101 or Long Pointer Format 117. If the field has the 
value 0, the pointer has Short Pointer Format 101. The 
value of Offset Field 105 is the offset of the UID-offset 
address represented by the pointer. Since Offset Field 
105 may only contain 31 bits, the maximum number of 35 
bits which may be addressed in an object is 2**31-2 bits, 
instead of of the 2**32- 1 bits specified in CS 10110. 

Long Pointer Format 117 is used for resolved UID 
pointers and unresolved pointers. Long Pointer Format 
117 contains four major fields: Format Specifier Field 40 
103, Offset Field 105, Flags and Format Field 107, and 
UID Field 115. Format Specifier Field 103 and Offset 
Field 105 are identical in size to their equivalents in 
Short Pointer Format 101. When Format Specifier 
Field 103 has the value 1, it specifies Long Pointer 45 
Format 117. In resolved UID pointers, Offset Field 105 
specifies the offset in the UID-offset address repre- 
sented by the pointer; in unresolved pointers it merely 
provides information from which the digital computer 
system may derive the UID-offset address. Flags and 50 
Format Field 107 is 16 bits long. It contains information 
required by the digital computer system of the present 
invention to interpret Long Pointer Format 117. It will 
be discussed in more detail below. In UID resolved 
pointers, UID Field 115 contains a UID. Together with 55 
the value of Offset Field 105, the UID specifies the 
UID-offset address represented by the pointer. In unre- 
solved pointers, UID Field 115, like Offset Field 105 
merely provides information from which the digital 
computer system may derive the UID-offset address 60 
represented by the pointer. 

Flags and Format Field 107 has three subfields: NR 
Field 111, System Software Codes Field 109, and For- 
mat Code Field 113. Beginning with NR Field 111, NR 
Field 111 is a single bit which indicates whether the 65 
pointer is resolved or unresolved. In Long Pointer For- 
mats 117 for resolved pointers, NR Field 111 has the 
value 0; in those for unresolved pointers, NR Field 111 
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has the value 1. In Long Pointer Formats 117 for unre- 
solved pointers, System Software Codes Field 109 con- 
tains information used by Procedures 00602 invoked by 
pointer resolve microde to derive the UID-offset ad- 
dress represented by the pointer. Format Code Field 
113, finally, specifies binary values which, together 
with NR Field 111 and Format Specifier Field 103, 
determine how the digital computer system of the pres- 
ent invention is to interpret a pointer having Long 
Pointer Format 117. The following table shows how 
Fields 103, 111, and 113 cooperate to specify a pointer’s 
type in the present invention: 



Field: 


103 


111 


113 


Meaning 




0 






Short Pointer Format: 
Resolved Object-Relative 
Pointer 

Long Pointer Format: 




1 


0 


0 


Resolved UID Pointer 




1 


1 


0 


Associative UID Pointer 




1 


1 


1 

2.. 128 


Associative Object- 
Relative Pointer 
Reserved Codes for Other 
Resolved and Unresolved 
Pointer Formats 



3. Null Pointers 

A null pointer is a pointer whose value indicates that 
the pointer does not represent an address. In CS 10110, 
a null pointer was indicated by setting Format Code 
Field 30113 to 0; in the present invention, a null pointer 
is indicated by setting Offset Field 105 to (2**31)— 1, 
i.e., by setting all of the bits in Offset Field 105 to 1 . 
Since only (2**31)— 2 bits of an object may be ad- 
dressed in the present invention, the value of the null 
pointer does not address a bit in an object. 

4. Advantages of Improved Pointer Formats 

The advantages of the improved pointer formats of 
the present invention stem from the fact that the first bit 
of any pointer indicates whether the pointer is a re- 
solved object relative pointer. Consequently, in the 
present invention, pointer processing microcode can 
determine on the first fetch of a pointer value from 
MEM 10112 whether extended processing will be re- 
quired. In CS 10110 as described in U.S. patent applica- 
tion Ser. No. 266,539 by contrast, bits 40 through 47 
indicated whether extended processing was required, 
and thus those bits had to be fetched even when the 
pointer was a resolved object-relative pointer and con- 
sequently contained all of the information actually re- 
quired to form an AON-offset address in Offset Field 
30103. The fact that a resolved object-relative pointer 
may be identified from the value of Format Specifier 
Field 103 is particularly important because pointers are 
most frequently used in CS 10110 and the present inven- 
tion to specify arguments to Procedures 00602. Gener- 
ally speaking, arguments used in an invocation of a 
Procedure 00602 by a Process 00610 are local data con- 
tained in other frames of Process 00610’s MAS 00502, 
and are therefore often in the same object as the frame 
for invoked Procedure 00602. When this is the case, the 
pointers specifying the arguments are resolved object- 
relative pointers and have Short Pointer Format 101. 

5. Pointer-to-Descriptor Conversion with Improved 
Pointer Formats 

The improved pointer formats of the present inven- 
tion greatly simplify pointer-to-descriptor conversion 
for resolved object relative pointers. In the present 
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12 



invention, pointer-to-descriptor conversion is carried necessary. DESC TO PTR next obtains the AONs 

out by a microroutine called PTR_TO_DESC. This of the first and second Logical Descriptors 27116 from 

microroutine’s listing appears in Appendix A. their AON Fields 27111 and compares them by means 

PTR_TO DESC takes a Logical Descriptor 27116 of an exclusive or (XOR) operation. IF the AONs are 



specifying the location of the pointer to be converted as 5 

its argument. When PTR TO DESC returns, logical 

Descriptor 27116 specifies the AON-Offset address 
corresponding to the UID-ofTset address represented by 
the pointer to be converted. 

PTR TO DESC first uses Logical Descriptor 10 

27116 to fetch the first 32 bit of the pointer which is to 
be converted to a descriptor from MEM 10112 to FU 
10120. In the improved pointer formats of the present 
invention, these 32 bits are Format Specifier Field 103 
and Offset Field 105. If Format Specifier Field 103 has 15 
the value 0, the pointer has Short Pointer Format 101 
and is a resolved object-relative pointer. Consequently, 
to complete the conversion, PTR _TO DESC simply 
copies the 32 bits fetched from MEM 10112 into OFF 
Field 27113 of Logical Descriptor 27116 and returns. 20 

If Format Specifier Field 103 of the fetched pointer 

has the value 1, PTR _TO DESC then fetches the 

next 32 bits, which includes Flags and Format Field 
107. Using the information in Flags and Format Field 
107, PTR TO^ DESC then proceeds in substantially 25 
the same manner as in CS 10110. If NR Field 111 indi- 
cates a resolved pointer, PTR TO DESC microcode 

fetches UID Field 115 and uses LAR microcode (de- 



the same, i.e., if the XOR operation has 0 as a result, the 
UID-offset address specifying the pointer’s location and 
the UID-offset address represented by the pointer are in 
the same object and the pointer is a resolved object-rela- 
tive pointer. When this is the case, the value of the first 
Logical Descriptor 27116’s OFF Field 27113 is written 
to MEM 10112 at the location specified by the second 
Logical Descriptor 27116. At this location, the value 
forms Format Specifier Field 103 and Offset Field 105 
of the pointer. If the AONs are different, the pointer is 
a resolved UID pointer and the descriptor-to-pointer 
conversion operation proceeds substantially as ex- 
plained in U.S. patent application Ser. No. 266,539. 

B. Namespace 

In descriptions of digital computer systems of the 
type of CS 10110, Namespace is a collective term for 
those portions of the system involved in the interpreta- 
tion of instruction stream syllables specifying operands. 
In U.S. patent application Ser. No. 266,539, Namespace 
is described in 3.B.a, b, and c. The following discussion 
presents improvements in certain elements of Names- 
pace in the present invention. It begins with a summary 
of these elements as described in U.S. patent application 



scribed in 4.B.e.3.c.c of U.S. patent application Ser. No. Ser. No. 

266,539) to convert the UID field’s value to an AON. 30 266,539 and then presents the improved elements of 

Once it has obtained the AON, it copies the AON into the present invention. 

Logical Descriptor 27116’s AON Field 27111 and the 1. Names and Name Table Entries in CS 10110 

offset from Offset Field 103 into OFF Field 27113. If In the S-instructions (SINs) executed by CS 10110, all 

NR Field 111 indicates an unresolved pointer and For- operands which represent UID-offset addresses in 
mat Code Field 113 an associated pointer, 35 MEM 10112 or data at locations specified by UID- 
PTR _TO DESC uses A AT 30201 to obtain the offset addresses are represented by Names. SINs are 
UID-offset address represented by the associated contained in Procedures 00602, and as shown in FIG. 
pointer as described in U.S. patent application Ser. No. 103 of U.S. patent application Ser. No. 266,539, each 
266,539 3. A.b, and then converts the UID address to an Procedure 00602 has associated with it a Name Table 
AON and proceeds as described above. Finally, if NR 40 10350. Each Name in a Procedure 00602 is an index of 
Field 111 and Format Code Field 113 indicate an unre- a Name Table Entry (NTE). The NTE associated with 
solved pointer other than an associated pointer, the Name contains information describing the location, 

PTR TO DESC performs a microcode-to-software length, and type of the operand represented by the 

Call to Procedures 00602 which resolve the pointer as Name. The location is described as a displacement from 
described in U.S. patent application Ser. No. 266,539 45 another location termed a base location. In the NTE, 
3 a . c. the base location, the length, and values used to calcu- 

6. Descriptor-to-Pointer Conversion with Improved late the location of array elements may be represented 
Formats by Names referring to other NTEs in Name Table 

Since all pointer formats in CS 10110 contained at 10350 containing the NTE in operation. The NTE, 
least Offset Field 30103 and Flags and Format Field 50 together with UID-offset addresses specified by Archi- 
30105, descriptor-to-pointer conversion in CS 10110 tectural Base Pointers (ABPs), is used by CS 10110 to 
always stored at least a 48-bit value in MEM 10112. calculate a logical Descriptor 27116 specifying the loca- 
These conversions are described in U.S. patent applica- tion, length, and type of the operand represented by the 
tion Ser. No. 266,539 3.A.d. In the present invention, Name. The operation of using a Name to locate the 
resolved object relative pointers are completely de- 55 NTE associated with it and then deriving a Logical 
scribed by Short Pointer Format 101, and consequently. Descriptor 27116 from the NTE and from the ABRs is 
when a Logical Descriptor 27116 is converted to a called Name Resolution; once a Name has been re- 
pointer, only 32 bits need be stored in MEM 10112. solved, the data at the location specified by Logical 

In the present invention, descriptor-to-pointer con- Descriptor 27116 may be fetched from MEM 10112 to 
version is carried out by the DESC_TO_PTR mi- 60 FU 10120. The operation combining Name Resolution 
croroutine, listed in Appendix A. DESC TO PTR and data fetching is called Name Evaluation. When a 
takes two arguments: a first Logical Descriptor 27116 NTE itself contains a Name, the Name Resolution or 
which the microroutine is to convert to a pointer, and a Evaluation operations are performed recursively to 
second Logical Descriptor 27116 specifying the loca- obtain the location or value represented by the Name, 
tion in MEM 10112 where the pointer is to be stored. 65 Name Resolution and Name Evaluation are explained in 

DESC TO PTR first places the value from the first detail in U.S. patent application Ser. No. 266,539 3.B.C. 1 

Logical Descriptor 27116’s OFF Field 27113 into a and 3.B.C.3. In CS 10110, information obtained by the 

register and then sets the value’s leftmost bit to 0 if Name Resolution operation for a given Name is en- 
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cached in Name Cache (NC) 10226 in FU 10120. On 
subsequent Name Resolution operations for that Name, 
the Name is simply presented to NC 10226, which then 
automatically makes the encached information avail- 
able. In simple cases, the encached information is Logi- 5 
cal Descriptor 27116 corresponding to the Name; in 
more complicated cases,, a signal from NC 10226 in- 
vokes Name Resolve microcode executing on FU 
10120. The microcode uses the encached information to 
produce Logical Descriptor 27116. If there is no infor- 10 
mation in NC 10226 for the Name, another signal from 
NC 10226 invokes Name Resolve microcode which 
performs a Name Resolution operation on the Name 
and then encaches the information resulting from the 
Name Resolution operation in NC 10226. Information 15 
produced by Name Resolution may be encached in NC 
10226 and accessed by means of the Name because there 
is only one Name Table for a given Procedure 00602, 
because there is only one NTE in a given Name Table 
for a given Name, and because the values in the ABPs 20 
do not change during an execution of a given Procedure 
00602. NC 10226 hardware is described in 2.B.2.b.b of 
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IES Field 30445 contains a Name or a literal value 
specifying the distance from the beginning of one 
element of an array to the beginning of the next 
element of the array. To locate an array elemen:, 
Name Resolution microcode multiplies the literal 
value of the value obtained by evaluating the Name 
by the value obtained by evaluating Index Name 
Field 30441. Again, whether IES Field 30445 con- 
tains a Name or a literal value is specified by a flag 
in Flags and Format Field 30407. 

While Names and Name Table 10350 provided CS 
10110 with a powerful and flexible means for specifying 
operands, the power and flexibility had their price: 

The fact that Names could have varying lengths 
greatly increased the complexity of CS 10110’s 
I-stream parsing mechanisms. 

The information required to resolve even simple 
Names, such as those referring to standard-sized 
operands located at offsets from ABPs, had to be 
obtained from Name Table 10350 in MEM 10112. 

In order to obtain the information to resolve a Name, 
a minimum of 64 bits had to be fetched from MEM 



U.S. patent application Ser. No. 266,539, and the 
method by which Name Resolution microcode main- 
tains NC 10226 is described in 3.B.3.e.e and 3.B.3.f.f. 5 

In CS 10110, a Name is an 8, 12, or 16-bit value with 
no internal structure, and a NTE has the format shown 
in FIG. 304 of U.S. patent application Ser. No. 266,539. 
The format is explained in detail in U.S. patent applica- 
tion Ser. No. 266,539 3.B.a.2; here, the format is ex- 
plained only in sufficient detail to provide an under- 
standing of the improved NTEs of the present inven- 
tion. NTE 30401 of CS 10110 may be either a Short 
NTE 30403 containing 64 bits or a Long NTE 30405 
containing 128 bits. As illustrated in FIG. 304, the first 
64 bits of a Long NTE 30405 contain the same fields as 
a Short NTE 30403. Short NTEs 30403 are used for 
scalar references whose displacements from the base 
location can be expressed in 16 bits; Long NTEs 30405 40 
are used for array references and scalar references 
whose displacements cannot be expressed in 16 bits. 

The functions of the fields in NTE 30401 may be 
summarized as follows: 

Flags and Format Field 30407 contains information 45 
from which Name Resolution microcode deter- 
mines whether NTE 30403 is a Long NTE 30405 
or a Short NTE 30403 and how NTE 30403 is to be 
interpreted. 

Base Field 30425 specifies a base location. Base Field 50 
30425 has three formats: in one, Base Field 30425 is 
a Name, in the second, Base Field 30425 specifies 
an ABP, and in the third, it specifies a pointer at a 
displacement from an ABP. Flags in Flags and 
Format Field 30407 determine how CS 10110 inter- 55 
pets Base Field 30425. 

Length Field 30435 specifies a length in bits. Length 
Field 30435 may be either a Name or a literal value. 

A flag in Flags and Format Field 30407 specifies 
which it is. 50 



10112 to FU 10120. 

In the improved Namespace of the present invention, 
the power and flexibility of Namespace in CS 10110 is 
retained and the results of Name Resolution operations 
may still be encached, but Names and the Name Table 
are improved so that certain Names can be resolved 
without reference to the Name Table and so that many 
Names can be resolved by fetching only 32 bits from the 
Name Table. Further, certain special provisions are 
made for NTEs specifying string data. These improve- 
ments reduce the size of Name Table 10350 and speed 
Name Resolution and Evaluation, thereby improving 
the efficiency of CS 10110. 

2. Improved Names 

As described above. Names in CS 10110 could vary 
in length but were all indexes into Name Table 10350. 
Since Names in CS 10110 were simply index values, 
they had no internal structure. In the present invention, 
all Names are 16 bits long, but there are two distinct 
kinds of names: Table Names, which, like the Names in 
CS 10110, specify NTEs in Name Table 10350, and 
Immediate Names, which do not specify NTEs and are 
resolved without reference to Name Table 10350. FIG. 
2 shows the formats of Table Names 201 and Immediate 
Names 209. Both Table Names 201 and Immediate 
Names 209 have NTY Field 203. NTY Field 203 speci- 
fies whether a Name is a Table Name 201 or an Immedi- 
ate Name 209 and, in the case of Immediate Names 209, 
further specifies an ABP. The following table gives the 
codes in NTY Field 203 and their meanings: 



Code in NTY Field 203 


Meaning 


n 


The Name is a Table Name 


00 


Immediate Name; ABP = FP 


0! 


Immediate Name; ABP — SDP 


10 


Immediate Name; ABP =• PBP 



DISP Field 30437 specifies a displacement from the 
base location specified by Base Field 30425. The 
displacement is always a literal value. 

DISP EXT Field 30439 is used together with DISP 
Field 30437 for displacements which cannot be 65 
expressed in 16 bits. 

Index Name Field 30441 contains a Name which is 
evaluated to obtain the value of an array index. 



In a Table Name 201, the remaining 14 bits make up 

NT IND Field 207, which specifies the index in a 

Name Table of the NTE corresponding to the Table 
Name. In an Immediate Name 209, the remaining 14 bits 
contain two fields: IB Field 205 and 32_DISP Field 
211. IB Field 205 is a one-bit flag which indicates 
whether the operand represented by Immediate Name 
209 may be located directly or indirectly. If IB Field 
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205 is set to 0, the operand represented by Immediate 
Name 209 is at the location specified by Immediate 
Name 209; if IB Field 205 is set to 1, the location speci- 
fied by Immediate Name 209 contains a pointer and the 
pointer’s value gives the location of the operand repre- 5 
sented by Immediate Name 209. The bit following IB 
Field 205 is reserved, and the remainder of Immediate 

name 209 is occupied by 32 DISP Field 211. 

32 DISP Field 211 contains a signed integer value 

which, when multiplied by 32, provides a displacement 10 
from the ABP specified in NTY Field 203. 

3. Name Resolution 

In CS 10110, all Names were resolved by means of 
Name Table 10350; in the improved digital computer 
system of the present invention, Table Names 201 are 15 
resolved by means of the Name Table and Immediate 
Names are resolved without the Name Table. FIG. 3 
provides a conceptual overview of the different meth- 
ods of Name Resolution in the present invention. Name 
Resolution Means 303 in FIG. 3 corresponds to Name 20 
Resolution microcode and NC 10226 in the present 
implementation. Name Resolution Means 303 is respon- 
sive to the value of NTY Field 203 and determines 
which method to use by the value of that Field in the 
Name being resolved. Beginning with Table Name Res- 25 
olution, this proceeds in the same manner as Name 

Resolution in CS 10110. Field NT IND 207 of Table 

Name 201 contains an index indicating an NTE 307 in 
Name Table 305. NTE 307 contains information de- 
scribing the base location, displacement, length, and 30 
type of the operand specified by Table Name 201, and 
Name Resolve Means 303 uses the information from 
NTE 307 together with the current values of ABPs 301 
to produce Logical Descriptor 27116 for the operand 
represented by the Name. 35 

Immediate Name Resolution, on the other hand, pro- 
ceeds without reference to a NTE 307. The base and 
displacement information required to resolve an Imme- 
diate Name 209 is provided by Immediate Name 209, 
and the RS and LEN Fields of Logical Descriptor 40 
27116 are set to standard values. To obtain the values of 
the AON and OFF fields, Name Resolve Means 303 

multiplies the value of 32 DISP Field 211 by 32 to 

obtain a displacement and then adds this displacement 
to the AON-offset form of the UID address contained 45 
in the ABP. Under SOP control, FU 10120 can override 
the standard values in the RS and LEN Fields. For 
example, if Immediate Name 209 appears at a location 
specified for an arithmetic operand in an integer arith- 
metic SIN, the SOP microcode will treat Logical De- 50 
scriptor 27116 produced by Name Resolve Means 303 
as a Logical Descriptor 27116 specifying an integer 
value. Similarly, if Immediate Name 209 appears where 
an operand specifying a pointer is required, the SOP 
microcode will treat Logical Descriptor 27116 as a a 55 
Logical Descriptor 27116 specifying a pointer value. 

If IB 205 is set to 1 in Immediate Name 209, the Name 
Resolution operation proceeds as just described, except 
that Name Resolution Means 303 responds to IB Field 
205 by fetching the pointer at the location specified by 60 

Immediate Name 209’s NTY Field 203 and 32 DISP 

Field 211 and performing a pointer-to-descriptor trans- 
lation on that pointer in order to obtain Logical De- 
scriptor 27116 for the operand represented by Immedi- 
ate name 209. 65 

4. Encachement of Information for Name Resolution 

As already mentioned, Name Resolution in CS 10110 

is speeded up by encaching information obtained by the 
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Name Resolution operation in NC 10226. In the present 
invention, information obtained from the resolution of 
both Table Names 201 and Immediate Names 209 may 
be encached. Table Names 201 are equivalent to the 
Names of CS 10110 and may be encached as they are. 
Immediate Names 209 are not indexes into Name Table 
305, but encachement is possible because the UID-offset 
addresses specified by ABPs 301 do not change their 
values while SINs in a given execution of a Procedure 
00602 are being interpreted by FU 10120. Conse- 
quently, all Immediate Names 209 specifying a given 
ABP in NTY Field 203 and having a given value in 
32 DISP Field 211 specify the same Logical Descrip- 

tor 27116 and that Logical Descriptor 27116 may be 
encached. Furthermore, since Immediate Names 209 
and Table Names 201 have different codes in NTY 
Field 203, they may function as keys to the same cache. 
In the embodiment of the present invention described 
herein, both Immediate Names 209 and Table Names 
201 are used as keys for NC 10226. If an Immediate 
Name 209 is presented to NC 10226 and NC 10226 
contains no information for that Immediate Name 209, 
NC 10226 produces a signal invoking Name Resolution 
microcode. Name Resolution microcode then resolves 
Immediate Name 209 and places the resulting informa- 
tion in NC 10226. In other embodiments of the present 
invention, Logical Descriptors 27116 corresponding to 
certain Immediate Names 209 may be separately en- 
cached. 

5. Improved NTEs 307 

As previously mentioned, NTEs 307 in the present 
invention have formats which allow many Table Names 
201 to be resolved after the first 32 bits of NTE 307 
specified by Table Name 201 have been fetched from 
from MEM 10112 to FU 10120. FIG. 4 presents an 
overview of Name Table 305 and NTE 307 in the pres- 
ent invention. Table Name 201 specifies the location of 
a NTE 307 in Name Table 305. NTE 307 is made up at 
least of Basic NTE 403. In some cases, a NTE 307 con- 
sists only of a Basic NTE 403. Indexes in Table Names 
201 always specify locations of Basic NTEs 403. How- 
ever, if a NTE 307 is an NTE 307 for array or string 
data, if it specifies a large displacement, or if it specifies 
a long or non-constant length, a NTE 307 further con- 
sists of one or more NTE Suffixes 411. DISP Suffix 405 
is used if NTE 307 specifies a large displacement, LEN 
Suffix 407 is used if NTE 305 has a large length or 
specifies certain string data, and IX Suffix 409 is used if 
NTE 305 is an array NTE 307. A given NTE 307 may 
have up to three NTE Suffixes 411. Only one NTE 
Suffix 411 of each kind may appear in a given NTE 307, 
and the suffixes always have the order in which they 
appear in FIG. 4. Flags in Basic NTE 403 specify which 
NTE Suffixes 411 follow Basic NTE 403 and how such 
NTE Suffixes 411 are to be interpreted. 

Basic NTE 403, IX Suffix 409, and LEN Suffix 407 
may themselves contain Table Names 201 or Immediate 
Names 209. When a Table Name 201 specifying an 
NTE 307 is resolved, the Names in NTE 307 are re- 
solved or evaluated as required to produce Logical 
Descriptor 27116 corresponding to Table Name 201. 
Names in NTEs 307 differ from those in SINs in only 
one respect: Immediate Names 209 in NTEs 307 may 
not specify an indirect reference from PBP. 

Turning now to FIG. 5, there is presented a detailed 
illustration of NTE 307 of the present invention. As 
explained above, NTE Suffixes 411 may or may not be 
present in a NTE 307, depending on the settings of flags 
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in Basic NTE 403. In FIG. 5, the conditions under 
which each NTE Suffix 411 is present are specified with 
the suffix. Further, parts of Basic NTE 403, LEN Suffix 
407, and IX Suffix 409 may have alternate fields, again 
depending on the settings of flags in Basic NTE 403. In 5 
FIG. 5, these alternate fields are represented by placing 
them below the parts of Basic NTE 403 or NTE Suffix 
411 which they occupy. The conditions under which 
the field has the meaning is specified with the alternate. 
For example, bits 16 through 31 of Basic NTE 403 io 
contain the field SDISP 515 when DL Field 511 is set to 
0 and the field BNAME 519 when ABPS Field 501 is 
set to the value 11. 

Beginning with Basic NTE 503, bits 1 through 7 of 
Basic NTE 503 contain flag fields which specify the 15 
form of NTE 307 containing Basic NTE 503 and the 
manner in which the fields of NTE 307 are to be inter- 
preted. The first of these fields is ABPS Field 501. If 
NTE 307 specifies an ABP as its base and the data is 
referenced directly, then ABPS Field 501 specifies the 20 
ABP; otherwise, it specifies that the data represented by 
NTE 307 is referenced indirectly and/or that NTE 307 
specifies its base by means of a Name. The codes in 
ABPS Field 501 and their meanings are the following: 



ABPS Code 


Meaning 


00 


FP ABP 


01 


SDP ABP 


10 


PBP ABP 


11 


Base is a Name or NTE 307 




specifies an indirect reference 



Bit 3 of Basic NTE 403 is reserved; bit 4 contains FIU 
Flag 505. FIU Flag 505 indicates whether data specified 
by NTE 307 is to be zero-filled or sign-filled when it is 35 
fetched from MEM 10112. A value of 0 specifies zero 
fill, and a value of 1 specifies sign fill. 

IX Field 507 specifies whether NTE 307 has an IX 
Suffix 409 and the manner in which Name Resolution 
Means 303 is to interpret IX Suffix 409. The codes in IX 40 
Field 507 and their meanings will be discussed in detail 
together with IX Suffix 409. LL Field 509 specifies the 
location of length information in NTE 307. If LL Field 
509 has the value 0, SLEN Field 513 in Basic NTE 403 
contains a literal value specifying the length and there is 45 
no LEN Suffix 407. If LL Field 509 has the value 1, 
there is a LEN Suffix 407 and SLEN Field 513 is re- 
placed by LU Field 518 and LP Field 616, which to- 
gether specify how Name Resolution Means 303 is to 
interpret LEN Suffix 407. The meanings of these fields 50 
will be discussed in detail together with LEN Suffix 
407. DL Field 511, finally, indicates the location of 
displacement information in NTE 307. If DL Field 511 
has the value 0, SDISP Field 515 contains the displace- 
ment information and there is no DISP Suffix 405. Oth- 55 
erwise, DL Field 511 has the value 1, indicating the 
presence of DISP Suffix 405. DISP Suffix 405 contains 
a single field, LDISP 521, and this field’s value is the 
displacement. 

BNAME Field 519 contains base information when 60 
ABPS Field 501 has the value 11. As stated above, 
ABPS Field 501 has that value when NTE 307’s base is 
a Name and/or the data specified by NTE 307 is refer- 
enced indirectly. BNAME Field 519 contains either an 
Immediate Name 209 or a modified version of Table 65 
Name 201. An Immediate Name 209 in BNAME Field 
519 specifies an indirect reference using a pointer found 
at a displacement from either the FP or the SDP ABP. 
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Consequently, Immediate Name 209’s IB Field 205 is 
always set to 1 and its NTY Field 203 is set to either 00 
or 01, specifying FP or SDP. Immediate Name 203 may 
not specify PBP. Modified Table Names 520 in 
BNAME Field 519 are Table Names 201 which have 
been modified to specify either a direct or indirect refer- 
ence whose base location is obtained from NTE 307 
specified by Modified Table Name 520. Modified Table 
Names 520 are distinguished from Table Names 201 by 
the use of NTY Field 203. In Table Names 201, NTY 
Field 203 must be set to 11; in Modified Table Names 
520, it may have the values 1 1 and 10. The value 1 1 
indicates that Modified Table Name 520 specifies a 
direct reference and the value 10 indicates that Modi- 
fied Table Name 520 specifies an indirect reference. The 
latter value is available for use in Modified Table Names 
520 because, as noted above, Immediate Means 209 in 
BNAME Field 519 cannot specify PBP. 

Turning now to the detailed representations of NTE 
Suffixes 411, DISP Suffix 405 contains a single field, 
LDISP 521, which contains a signed 32-bit value speci- 
fying a displacement from the base indicated by NTE 
307 to which DISP Suffix 405 belongs. As mentioned 
25 above, DISP Suffix 405 is present only if SDISP Field 
515 is not present or is too short to specify the displace- 
ment. DISP Suffix 405’s presence is specified by DL 
Field 511. 

IX Suffix 409 has two parts. Bits 0 to 15 contain IX- 
30 NAME Field 529, while bits 16 to 31 contain three 
alternate fields: IESVAL 531, IESNAME 533, and 
IESSH 535. IXNAME Field 529 contains a Table 
Name 201 or an Immediate Name 209 which represents 
data used as an index in a reference to an element of an 
array. When Table Name 201 specifying NTE 307 con- 
taining IX Suffix 409 is resolved, the Name in IX- 
NAME Field 529 is evaluated to obtain the index value. 
The alternate fields in bits 16 to 31 specify the distance 
separating the first bits of elements of the array. That 
distance, multiplied by the index value obtained by 
evaluating the Name in IXNAME Field 529, yields the 
location of an element of the array. Which of the alter- 
nate fields is present is indicated by codes in IX Field 
507 in Basic NTE 403. The codes are as follows: 



Code in IX Field 507 


Meaning 




00 


IX Suffix 509 not present. 




01 


IX Suffix present, bits 16-31; 
IESVAL 531 




10 


IX Suffix present, bits 16-31: 
IESNAME 533 




11 


IX Suffix present, bits 27-31: 
IESSH 535 





The alternate fields in bits 16 to 31 represent the 
distance between elements of arrays in three ways: 
IESVAL 531 contains a 16-bit literal value which 
specifies the distance between elements. 
IESNAME 533 contains a Table Name 201 or an 
Immediate Name 209 upon which a Name Evalua- 
tion Operation is performed to obtain a value speci- 
fying the distance between the elements. 

IESSH 535 contains a 5-bit value specifying a power 
of two. The value obtained from IXNAME 529 is 
multiplied by this power of 2 (i.e., shifted to the left 
that many bits) to obtain the location of the array 
element. 
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LEN Suffix 407, present only if LL Field 509 has the 
value 1, is used for two purposes: 

To specify data whose length in bits is greater than 
the length which can be specified by SLEN Field 
513 in Basic NTE 403. 5 

To specify data whose length may vary during execu- 
tion of the program. 

Data whose length may vary during the execution of 
a program is typically string data, that is, data made up 
of an arbitrary sequence of elements of some data. Most 
high-level languages have character-string data, in 
which the elements making up the sequence are repre- 
sentations of characters. Other high-level languages 
additionally have bit-string data, in which the elements 
making up the sequence are single bits, and a few have 15 
string data whose elements may have any data type. 
Typically, string data whose length may vary contains 
a value specifying the number of elements currently in 
the string in addition to the elements making up the 
string data’s current value. The value specifying the 2 
number of elements is termed a dope vector value. The 
dope vector value is generally located just ahead of the 
first element in the string. The address of a string gener- 
ally specifies the location of the first element of the 2J 
string, and the dope vector is located by means of an 
offset from the string’s address. LEN Suffix 407 of the 
present invention make special provision for the facts 
that the elements of different kinds of string data may 
have different sizes, the 8-bit elements are particularly 3Q 
frequent, and that string data typically has a dope vec- 
tor value. 

In CS 10110, variable-length strings have NTEs spec- 
ifying a Name which is evaluated to obtain the string’s 
length in bits, The Name generally specifies a dope 35 
vector, and the dope vector must consequently specify 
the number of bits, not the number of elements in the 
string. Consequently, the frequent operations which 
interrogate the dope vector to determine the number of 
elements currently in the string must divide the dope 40 
vector by the size of the elements. In the present inven- 
tion, a Name is no longer required to locate the dope 
vector. Furthermore, the length of a string is to be 
obtained by multiplying a value specifying a length by a 
value specifying the size of a unit, and the dope vector 45 
can thus specify the current number of elements in the 
string instead of the current number of bits. Finally, as 
with arrays, the present invention takes advantage of 
the fact that elements of many strings have sizes that are 
powers of 2 to accelerate the calculation of the string’s 50 
length. 

LEN Suffix 407 has three basic forms: 

It may contain the single 32-bit field LENVAL 525. 
LENVAL 525 contains an unsigned literal value 
specifying the length of the data item represented 55 
by Table Name 201 corresponding to NTE 307 to 
which LEN Suffix 407 belongs. 

It may be two 16-bit fields, one, LENNAME 527, 
containing a Table Name 201 or Immediate Name 
209 which, when evaluated, yields the number of 60 
elements in the data item represented by Table 
Name 201 corresponding to NTE 305 to which 
LEN Suffix 407 belongs and another, UNITS 532, 
which yields a value specifying the size of the ele- 
ments in the data item. 65 

It may be UNITS Field 532 by itself. In this case, the 
number of elements is obtained from the dope vec- 
tor. 
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UNITS Field 532 contains three alternate sets of fields 
for representing the size of the elements: 

UVAL Field 526 contains a positive integer value 
representing the size of the elements. 

UNAME Field 528 contains either a Table Name 201 
or an Immediate Name 209. When the Name is 
evaluated, it yields an integer value representing 
the size of the elements. 

LSH Field 530 contains a 5-bit value specifying a 
power of 2. The value specifying the number of 
elements in the data item is multiplied by this 
power of 2 (i.e. shifted to the left that many bits) to 
obtain the length of the data item. 

The manner in which LEN suffix 407 is interpreted 
by Name Resolve microcode is determined by the val- 
ues of LU Field 518 and LP Field 516 in Basic NTE 
403. LU Field 518 has the primary role here, and LP 
Field 516 is interpreted only when the length informa- 
tion for the data item is contained in a dope vector. LU 
Field 518 has the following codes: 



Code in LU Field 518 


Meaning 


00 


LEN Suffix 407 consists of LENVAL 
525 


01 


UNITS 532 is UVAL 526 


10 


UNITS 532 is UNAME 528 


11 


UNITS 532 is LSH 530 



If LU 518 has a value other than 0 and LP 516 has a 
value greater than 0, finally, the length information is 
contained in a dope vector. In this case, LP 516 is inter- 
preted. LP 516 contains a positive integer value ranging 
from 0 to 32 which specifies the number of bits ahead of 
the data item’s address at which the dope vector begins. 
LP 516 thus makes it possible to specify the location of 
the dope vector without using a name and to fetch the 
dope vector’s value without a name resolution opera- 
tion. 

The advantages of NTEs 307 having the format just 
described may be summed up as follows: 

NTEs 307 for Table Names 201 representing scalar 
data with lengths of 127 bits or less and either a 
Name as a base or a displacement of up to (2** 15)- 1 
from an ABP are made up of a single 32-bit Basic 
NTE 403. In CS 10110, all NTEs were at least 64 
bits long. 

Most other scalar data can be represented by a Basic 
NTE 403 with either a DISP Suffix 405 or a LEN 
Suffix 407, and therefore in the same 64 bits which 
was the minimum size of a NTE in CS 10110. 

Elements of many arrays can be represented by a 
Basic NTE 403 and an IX Suffix 409; elements of most 
other arrays can be represented by adding either a 
DISP Suffix 405 or a LEN suffix 407; in CS 10110, all 
array NTEs required 128 bits. 

Immediate Names 209 may be more quickly resolved 
than Table Names 201, and consequently, the use 
of Immediate names 209 in NTEs 307 speeds the 
resolution of these NTEs 403. Since Immediate 
Names 209 have no NTEs 307, their use also re- 
duces the size of Name Table 305. 

IESSH Field 435 and LSH Field 530 both directly 
specify a shift operation therefore allow more rapid 
resolution of array NTEs and NTEs for strings in 
the frequent cases where the distance between the 
elements is a power of 2. 
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UNITS Field 532 allows the dope vector to contain contains the length information. The DL Field is set to 
the number of units in the string, instead of the 1, indicating the presence of a DISP Suffix, and the 
number of bits. SLEN Field is set to 32, the length of the integer values 

LP Field 516 in Basic NTE 403 makes it possible to in LIST. As indicated by the setting of the ABPS Field, 
locate a dope vector for a string without resolving 5 the last 32 bits of the Basic NTE are occupied by Field 
a Name. BNAME. Since Linkage Pointer for LIST 605 is in 

6. Combined Advantages of Immediate Names 209 SORT Stack Frame 603, Field BNAME contains an 

and NTEs 307 Immediate Name 209 specifying Linkage Pointer for 

In combination; Immediate Names 209 and NTEs 307 List 605 and an indirect reference. The NYT Field in 
are particularly powerful. This may be shown by re- 10 BNAME is therefore set to 00, specifying FP, the IB 
peating the FORTRAN example of U.S. patent applica- Field is set to 1, specifying an indirect reference, and the 
tion Ser. No. 266,539 3.B.e.3.a.a for the present inven- 32 DISP Field specifies —8, which, when multiplied 
tion. As shown in U.S. patent application Ser. No. by 32, gives the displacement of Linkage Pointer for 
266,539 3.B.c.3.a.a, the FORTRAN compiler generated List 605 from FP. 

Names from the following declarations: 15 As previously mentioned, the DISP Suffix in NTE 

SUBROUTINE SORT (LIST) for LIST(I) 601 contains —32, the value required to 

correct for the fact that the index of the first element of 
INTEGER LIST (10) a FORTRAN array is 1. Continuing with the IX Suffix, 

INTEGER I, N, TEMP the IXNAME Field contains a Name representing I. 

FIG. 305 of U.S. patent application Ser. No. 266,539 20 Since I is local data, it may be located by a displacement 
shows the stack frame for an invocation of SORT and from FP, and consequently, the IXNAME Field con- 
the NTEs for I and LIST(I). FIG. 6 of the present tains an Immediate Name 605. In that Immediate Name, 
application shows Stack Frame for SORT 603 and NTE the NTY Field is set to 00, specifying FP, the IB Field 
for LIST(I) 601 in the present invention. In addition, it is set to 0, specifying a direct reference, and the 

shows the IMOV SIN for LIST (I)=TEMP 615. This 25 32 DISP Field is set to 0, specifying I’s displacement 

SIN is generated by the FORTRAN compiler from the from FP. The remaining 16 bits of the IX Suffix contain 
FORTRAN statement the IESSH Field, as specified by the IX Field in the 

LIST (I) = TEMP Basic NTE. The IESSH Field contains the value 5, 

in SORT. The equivalent SIN is not shown in FIG. 305 since 32, the distance between array elements in LIST, 
of U.S. patent application Ser. No. 266,539, but as is 30 is 2 raised to the 5th power. 

obvious from the discussion of SINs in U.S. patent ap- Turning now to IMOV SIN for LIST(I)=TEMP 
plication Ser. No. 266,539, it consists of an SOP, a Name 615, the IMOV SIN consists of the SOP and two 

for TEMP, and a Name for LIST(I). Names: one representing the source of the value to be 

Turning first to SORT Stack Frame 603, it is substan- assigned and the other representing the destination to 
tially equivalent to SORT Stack Frame 30501. Storage 35 which it is to be assigned. In the IMOV of FIG. 615, the 
for the 32-bit local data I, N, and TEMP is at positive first Name is Immediate Name for TEMP 619 and the 
displacements from FP and storage for the linkage second is Table Name for LIST(I) 621. The storage for 
pointer to the actual for the formal argument LIST is at TEMP is located at a displacement of 64 bits from FP, 
a negative displacement from FP. An additional area, and consequently, the NTY Field in Immediate Name 
Basic Save Area 607 is located between FP and Linkage 40 for TEMP 619 is set to 00, the IB Field is set to 0, and 

Pointer for LIST 607, but this area is relevant to this the 32 DISP Field is set to 2, which, when multipled 

discussion only to the extent that it affects the location by 32, yields 64. The contents of Table Name for 
of Linkage Pointer for LIST 605. LIST(I) 621 specify the location of NTE for LIST(I) 

Turning now to NTE for LIST(I) 601, NTE for 601 in Name Table 305 for SORT. 

LIST(I) 601 consists of a Basic NTE 403, a DISP Suffix 45 When IMOV SIN for List(I)=TEMP 615 is exe- 
405, and an IX Suffix 409. DISP Suffix 405 is required cuted, the first Name is evaluated and the second is 
because the index of the first element of a FORTRAN resolved. Since Immediate Name for TEMP 619 is an 
array is 1 instead of 0, and consequently, the address Immediate Name 209, it is resolved and evaluated with- 
produced by multiplying the index value by the distance out reference to Name Table 305. The resolution of 
between the elements is always that of the element 50 Table Name for LIST(I) 621 requires NTE for LIST(I) 
following the desired element. To correct for this, the 601. The resolution involves the following operations: 
compiler includes DISP Suffix 405 in NTE for LIST(I) The base location is obtained by resolving Immediate 
601, negates the distance between elements of the array, Name 209 in the BNAME Field. Since Immediate 

and sets DISP Suffix 405 to that value. In the Name Name 209 specifies an indirect reference, the Name 

Resolution operation, the value of DISP Suffix 405 is 55 Resolve Operation first locates and then evaluates 

added to the value produced from the index value and Linkage Pointer for List 605. 

the distance between element of the array, so that the The index value is obtained by evaluating Immediate 
address is that of the desired element instead of the Name 209 in the IXNAME Field of the IX Suffix, 

following element. The displacement is calculated by shifting the index 

Beginning with Field ABPS in NTE for LIST (I) 60 value to the left as specified by the IESSH Field, 
601, that field is set to 11. The setting is a consequence subtracting the value of the LDISP Field, and 

of the fact that LIST is a formal argument. Its base adding the result to the base location, 

location is contained in Linkage Pointer for List 605 and Since the Names in NTE for LIST(I) 601 are all 
reference to LIST are indirect. The FIU Field is set to Immediate Names 209, they can be resolved without 

1 because integer values are sign extended. The IX 65 further reference to Name Table 305 and only NTE for 
Field is set to 1 1, indicating that there is an IX Suffix LIST(I) 601 need be fetched from MEM 10112. 
and that the IESSH Field is present in that suffix. The In the IMOV SIN of CS 10110, three NTEs were 
LL Field is set to 0, indicating that the SLEN Field required for the Names in the SIN and the NTE; fur- 
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thermore, references to Name Table 10350 were re- 
quired to resolve all three names; with the improved 
Names and NTEs 307 of the present invention, only a 
single Table Name 201 is required and only one of the 
Name Resolution operations need refer to Name Table 5 
305. Moreover, in CS 10110, two of the three references 
were to 64-bit NTEs, and the third was to a 128-bit 
NTE. Consequently, 256 bits of NTE had to be fetched 
from MEM 10112 to FU 10120. With the improved 
Name Table Entries of the present invention, only a 10 
single 96-bit NTE need be fetched. 

7. Implementation of Name Resolution and Evalua- 
tion in the Present Invention 
The implementation of Name Resolution and Evalua- 
tion in the present invention is substantially the same as 15 
in CS 10110. A Name is first presented to NC 10226. If 
a hit occurs, NC 10226 produces either the Logical 
Descriptor 27116 corresponding to the Name or a JAM 
signal which invokes FU 10120 Name Resolve Micro- 
code. The microcode invoked by the JAM signal then 20 
produces a Logical Decriptor 27116 from the informa- 
tion in NC 10226 for the Name. If a miss occurs, another 
JAM signal invokes further FU 10120 NAME Resolve 
Microcode which resolves the Name as described 
above and then makes a NC 10226 Entry for the Name, 25 
Such changes in the microcode as are necessary to ac- 
comodate Immediate Names 201 and improved NTEs 
305 are immediately apparent to one skilled in the art, as 
may be seen from the RESOLVER TRAPS and RE- 
SOLVER microcode included in Appendix A. 30 

C. The I-Stream 

When JP 10114 executes a Procedure 00602, it fet- 
ches and executes a sequence of SINS from Procedure 
00602. The sequence of SINs being executed by JP 35 
10114 is termed the Instruction Stream (I-stream). As 
described in U S. patent application Ser. No. 266,539, 
the I-stream of CS 10110 is made up of eight-bit SOPs 
and operand syllables having lengths of 8, 12, or 16 bits. 

All operand syllables in a given Procedure 00602 have 40 
the same size and a field in PED 30305 belonging to a 
given Procedure 00602 specifies the operand syllable 
size for that Procedure 00602. The operand syllables in 
the I-stream can be either Names specifying NTEs con- 
taining location, type, and length information for the 45 
operands represented by the Names or Literal Syllables 
containing signed values used directly as data by JP 
10114. The I-stream in CS 10110 is described in detail in 
U.S. patent application Ser. No. 266,539 3.B.3.g.g. and 
h.h. 50 

While the I-stream in CS 10110 was more regular, 
and therefore more adapted to high-speed parsing than 
the I-streams of other digital computer systems having 
S-languages, experience with CS 10110 showed that 
still more regularity was desirable: 55 

The use of SOPs whose size differed from that of the 
operand syllables required complicated parsing 
mechanisms and made the task of building cost-ef- 
fective small versions of CS 10110 more difficult. 
Name Tables 10350 tended to be large, and conse- 60 
quently, 8-bit and 12-bit Names were infrequently 
used. 

The restriction of opcodes to 8 bits made it necessary 
to place information required for the execution of 
certain SOPs in a Literal Syllable following the 65 
opcode. The Literal Syllable increased the size of 
the SIN and execution of the SIN was slowed 
because an additional parsing operation was re- 
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quired to obtain the information in the literal sylla- 
ble. 

Since different Procedures 00602 had different sylla- 
ble sizes, the syllable size had to be saved and restored 
when Call and Return SINs were executed and when a 
Virtual Processor 00612 was removed from JP 10114 
and then rebound to JP 10114. 

1. The Improved I-stream 

To overcome these problems, the present invention 
has made the SOP and all operand syllables 1 6 bits long. 
FIG. 7 illustrates the improved I-stream of the present 
invention. FIG. 7 represents a single SIN 711, consist- 
ing of an SOP 701 and a sequence of Operand Syllables 
707. SOP 701 and Operand Syllables 707 are all 16 bits 
long. An Operand Syllable 707 may be an I-stream 
Literal 709, a Table Name 201, or an Immediate Name 
209. Table Names 201 and Immediate Names 209 have 
already been described in detail; I-stream Literal 709 is 
a 16-bit signed integer value. 

SOP 701 contains two eight-bit fields. Opcode Field 
703 contains SOP 701’s opcode. In most SINs, the op- 
code in Opcode Field 703 completely specifies the oper- 
ation to be performed by JP 10114 when it executes SIN 
711. OM Field 705 contains an additional eight-bit value 
which is used in the execution of the operation specified 
by Opcode Field 703. The value in OM Field 705 may 
have one of three functions, depending on SIN 711: 

In SINs 711 specifying branches (i.e., non-sequential 
transfers of control from one SIN 711 to another 
within a Procedure 00602), OM Field 705 may 
contain a signed literal value specifying the loca- 
tion relative to the branch SIN 711’s SOP 701 of 
the next SIN 711 to be executed. 

In SINs 711 specifying Calls to other Procedures 
00602, OM Field 705 contains a value specifying 
the number of arguments used in the Call. 

In certain other SOPs, the value in OM Field is a 
secondary opcode. In these SOPs, Opcode Field 
703 and OM Field 705 together form a single 16-bit 
opcode. 

In the branch SINs of CS 10110, the literal value 
specifying the location of the next SIN to be executed is 
contained in a Literal Syllable following the SOP, and 
this Syllable had to be fetched and parsed before the 
SOP could perform the branch. One of the chief uses of 
branch SOPs is in loops, and since most of the execution 
time of many programs is spent executing loops, the 
additional overhead required to fetch the lateral syllable 
has an adverse effect on performance. In the present 
invention, the S-interpreter microcode executing a 
branch SIN 711 checks the value of OM Field 705; if 
OM Field 705’s value is not equal to 0, the S-interpreter 
microcode multiplies OM Field 705’s value by 16 and 
adds it to the current value of IPC 20272 to obtain the 
location of the next SIN 711. Otherwise, the S-inter- 
preter microcode causes the next Operand Syllable 707 
to be parsed. This Operand Syllable contains a 16-bit 
literal value, and the S-interpreter microcode multiplies 
that value by 16 and adds it to IPC 20272 as described 
above. Since OM Field 705’s values may range from 
—255 to +255, it can specify branches to SINs 711 
located within 266 16-bit syllables of the Branch SOP 
701. Loops executed with very high frequency tend to 
have branches within this range of values, and conse- 
quently, the use of OM Field 705 for the literal value 
significantly increases the speed with which programs 
execute on the present invention. 
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Like branches, Calls are frequently-performed opera- 
tions. In the Call SINs 711 of CS 10110, the number of 
arguments in the Call is specified by a literal operand 
syllable, and this syllable has to be fetched as part of 
every Call operation. Furthermore, since Procedures 5 
00602 typically have only 2 or three arguments and 
virtually never take more than 10, the 8, 12, or 16 bits of 
the literal value were far more than required to specify 
the number of arguments. In the present invention, the 
number of arguments is specified by OM Field 705 and 10 
an I-stream Literal 709 is therefore no longer required 
in Call SINs 711 of the present invention. Since the 
number of arguments is always positive, OM Field 705 
can specify up to 51 1 arguments, far more than required 
for any practical Procedure 00602. 15 

In certain SINs 711 which are infrequently used or 
whose execution is generally of long duration, OM 
Field 705 is used as a secondary opcode. JP 10114 ob- 
tains the primary opcode from Opcode Field 703 and 
then, as specified by that opcode, obtains a secondary 20 
opcode from OM Field 705. The primary and second- 
ary opcodes together define the operation. OM Field 
705 is not so used in SINs 711 which are frequently used 
or may be quickly executed because of the additional 
time required to evaluate OM Field 705. 25 

The intrinsic functions defined by the FORTRAN 
language provide an example of the use of OM Field 
705 as a secondary opcode. These intrinsic functions 
perform complex mathematical operations such as the 
calculation of trigonometric functions and square roots. 30 
The time required to perform such operations is gener- 
ally much greater than the time required to perform 
simple arithmetic operations, and the extra time re- 
quired for the evaluation of OM Field 705 is insignifi- 
cant compared with the time required to perform the 35 
intrinsic operation itself. Consequently, all SOPs speci- 
fying FORTRAN intrinsic operations have a primary 
opcode of decimal 14 in Opcode field 703 and the value 
of OM Field 705 specifies the specific intrinsic opera- 
tion. For example, in the CGOS SOP for the cosine 40 
operation, OM Field 705 has the value decimal 4, and in 
the GSIN SOP for the sine operation, OM Field 705 has 
the value decimal 11. 

In the present invention, the exclusive use of 16-bit 
Operand Syllables 707 has another advantage: as de- 45 
scribed above, Immediate names 209 require four bits 
for NTY Field 203, IB Field 205, and the reserved bit 
following IB Field 205. If Operand Syllables 707 could 
have lengths of 8, 12, or 16 bits, as in CS 10110, some 
immediate names 209 would have 32 — DISP Fields 50 
211 containing 4 bits and other would have 32_DISP 
Fields 211 containing 8 bits. The small range of dis- 
placement values possible in 4 or 8-bit 32_DISP Fields 
211 would greatly reduce the utility of Immediate 
Names 209 in the present invention. 55 

As may be seen from the above description, the im- 
proved I-stream of the present invention has five main 
advantages over the I-stream of CS 10110; 

The exclusive use of 16-bit syllables simplifies pars- 
ing, thus reducing hardware costs for the machine. 60 
There is no longer any need to save and restore a 
value specifying syllable size on Calls and Returns 
and when a Virtual Processor 00612 ceases and 
resumes execution on JP 10114. 

The addition of OM Field 705 to the SOP syllable 65 
allows the elimination of I-stream Literals from 
certain frequently-executed SINs 711, thereby 
speeding the execution of these SINs 711. 
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The use of OM Field 705 for secondary opcodes 
allows longer opcodes for infrequent operations or 
operations of long duration without reducing the 
speed of other operations. 

16-bit Names allow the extensive use of Immediate 
Names 209 and therefore speed up Name Resolu- 
tion and reduce the size of Name Table 305 as 
previously described. 

Taken together, these advantages allow significant 
cost reductions and performance improvements in com- 
puter systems of the present invention. 

2. Implementation of the 16-bit I-stream in the Pres- 
ent Embodiment 

The present embodiment still employs the parsing 
hardware of CS 10110. The hardware itself is described 
in Chapter 2.B.3.b.b.a.a.a, of U.S. patent application 
Ser. No. 266,539, and the microcommands which con- 
trol the hardware in Chapter 3.B.3.h.h. In the present 
embodiment, parsing microcode modifies the behavior 
of the parsing hardware so that it correctly parses the 
I-stream of the present invention. On beginning the 
execution of a SIN 711, parsing microcode uses the 
parse _ op _ stage microcommand as in CS 10110 to 
fetch Opcode Field 703. Then it sets CSSR 24112, 
which contained the syllable size, K, in CS 10110, to 8 

and uses the parse _k _load epc command to fetch 

OM Field 705 and place its value on NAME 20224. 
Finally, it sets CSSR 24112 to 16 and fetches the SIN’s 
Operand Syllables 707. In other embodiments, CSSR 
24112 may be omitted and the parsing hardware may 
always fetch 16-bit syllables. The microcode which 
performs the above operations is contained in EMULA- 
TE_2400 of Appendix A. 

D. Accumulator SOPs 

Each instruction which may be executed on a digital 
computer system may be said to specify a machine upon 
which the operation indicated by the instruction is exe- 
cuted. For example, an ADD instruction on a typical 
traditional digital computer system specifies two regis- 
ters which contain the value to be added, an ALU to 
perform the operation, and a third register to hold the 
result. These three registers and the ALU are the “ma- 
chine” with which the addition operation is performed. 

Taken together, the set of instructions which may be 
executed on a digital computer system specifies a con- 
ceptual machine consisting of all of the “machines” 
specified by the individual instructions. This conceptual 
machine is termed the digital computer system’s archi- 
tecture. If two digital computer systems have the same 
architecture, they will execute the same instructions in 
the same manner, regardless of any differences in the 
physical devices making up the digital computer sys- 
tems. 

1. Traditional Architectures 

The conceptual machines specified by instruction sets 
for instructions for traditional digital computer systems 
of the prior art typically specify operations in terms of 
registers and operations performed by an ALU on the 
contents of those registers. Thus, the kind of operations 
typically specified by statements in high-level languages 
such as FORTRAN must be carried out by a sequence 
of several instructions. The following FORTRAN frag- 
ment can provide an example of this relationship be- 
tween high-level language statements and instructions 
in traditional digital computer systems. 
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REAL SUM, VALA, VALB 
SUM = VALA + VALB 



The instructions corresponding to the statement 

SUM = VALA + VALB 
typically include the following: 

(1) a first load instruction which loads the value at the 
location specified by VALA from memory into a 
first register. 

(2) a second load instruction which loads the value at 
the location specified by VALB into a second reg- 
ister. 

( 3 ) a floating point add arithmetic instruction which 
specifies the first and second registers as sources 
for an ALU which performs floating point arithme- 
tic. Output from the ALU goes to a result register. 

(4) a store instruction which stores the contents of the 
result register at the location specified by SUM. 

In many cases, further instructions preceding the above 
instructions may be required to set up addressing regis- 
ters so that they specify the locations of the variables. 

2. SIN Architecture of CS 10110 

The conceptual machine required to execute the 25 
SINS of CS 10110 described in U S. patent application 
Ser. No. 266 , 539 , is represented in FIG. 8. In order to 
establish the relationship between the conceptual ma- 
chine and the devices in CS 10110 which actually per- 
form the operations specified by the SINs, there is listed 30 
with each conceptual device the corresponding devices 
from FIG. 270 of U.S. patent application Ser. No. 
266 , 539 . 

The devices of the conceptual machine of FIG. 8 
include: 

Memory 801 (MEM 10112), in which data and Proce- 
dure Objects 00608 are stored. Procedure Objects 
00608 contain Procedures 00602, containing se- 
quences of SINs, and Name Tables 10350, contain- 
ing NTEs for the Names in the SINs of Procedures 40 
00602. When a Procedure 00602 is being executed, 
it uses data contained in a stack, MOS 00502, and a 
Static Data Block 46863. A Procedure 00602 may 
also use other data in Memory 801. 

Memory Output 803 (MOD 10114), which transmits 45 
data from Memory 801 to Calculating Unit 815 and 
SINs from Memory 801 to I-stream Reader 805. 

I-stream Reader 805 (I-Stream Reader 27001), which 
parses SINs obtained from Memory 801 into SOPs, 
Names, and Literal Syllables, The syllables are 50 
output on Syllable Output 807. In addition, I- 
stream reader generates descriptions specifying the 
locations of syllables in Memory 801. These de- 
scriptors are output onto Descriptor Output 806 
(DB 27021). I-stream Reader 805 further contains 55 
two registers whose values are used to generate 
descriptors: PC, specifying the address of the next 
SIN to be fetched in Procedure 00602 being exe- 
cuted, and K, specifying the syllable size of Oper- 
and Syllables in Procedure 00602. 60 

Syllable Output 807 (NAME 20224), which delivers 
syllables parsed from the I-stream by I-stream 
Reader 805 to SOP Decoder 809, Name Translator 
811, and Calculating Unit 815. 

SOP Decoder 809 (SOP Decoder 27003), which de- 65 
codes SOPs obtained from Syllable Output 807 and 
produces control signals to which the devices of 
the conceptual machine of FIG. 8 respond. SOP 



28 

Decoder 809 also contains an SIP register contain- 
ing a value which specifies the S-interpreter being 
used to decode the SOPs. 

Name Translator 811 (Name Trans. Unit 27015), 
which resolves and evaluates Names obtained from 
Syllable Output 807 and produces descriptors 
(Logical Descriptors 27116) which it outputs to 
Descriptor Output 806. Name Translator 811 con- 
tains four registers: three contain the ABPs: FP, 
specifying the location in MOS 00502 of the frame 
for the current execution of Procedure 00602, 
SDP, specifying the location of Static Data Block 
46863 being used for the current execution of Pro- 
cedure 00602, and PBP, specifying a location in 
Procedure Object 00608 containing Procedure 
00602. The fourth contains NTP, specifying the 
location of Name Table 10350 for Procedure 00602 
in Procedure Object 00608. 

Memory Signal Generator 812 (Memory Ref. Unit 
27017, Prot. Unit 27019) takes descriptors from 
Descriptor Output 806 and produces memory sig- 
nals containing addresses and indicating read, 
write, and execute operations. Memory Signal 
Input 813 (PD 10146) carries these signals to Mem- 
ory 801. 

Calculating Unit 815 (EU 10122), finally, receives 
data from Memory 801 via Memory Output 803 
and I-stream Literals from I-stream Reader 805 via 
Syllable Output 807. It processes its inputs as speci- 
fied by the SOP and outputs the result to Memory 
Input 817 and thereby to Memory 801. 

Unlike the conceptual machines specified by instruc- 
tions of the traditional digital data processing system, 
conceptual machine of FIG. 8 contains no general-pur- 
pose registers. The contents of the registers specified in 
FIG. 8 may be changed only by certain SINs, and only 
in narrowly-defined ways. Beginning with the PC regis- 
ter in I-stream Reader 805, only Branch SINs and Call 
and Return SINs may explicitly set the PC register to a 
new value. All other SINs merely implicitly increment 
the PC register to specify the next SIN. 

The registers K in I-stream Reader 805, SIP in SOP 
Decoder 809, and FP, SDP, PBP, and NTP in Name 
Translator 811, may only be set to new values by Call 
and Return SINs. The Call SIN saves the current values 
of K, SIP, FP, SDP, PBP, and NTP on the frame in 
MOS 00502 for the execution of Procedure 00602 exe- 
cuting the Call SIN and then sets these registers to the 
new values required for Procedure 00602 being called. 
The Return SIN sets these registers to the values saved 
on the frame in MOS 00502 for the execution of Proce- 
dure 00602 to which the Return SIN returns. 

The operations performed by the conceptual machine 
defined by CS 10110 corresponds closely to the opera- 
tions specified by statements in high-level languages. 
Generally, therefore, few SINs are generally needed to 
carry out the operations specified by such a statement. 
For example, in CS 10110, the FORTRAN statement of 
the above example corresponds to a single FORTRAN 
SIN, specified as follows: 

FADD nl, n2, n3 

FADD indicates the opcode, in this case, 60, and nl, n2, 
and n3 indicate three Names. The operation specified 
for FADD is the addition of evaluated nl to evaluated 
n2 and the storage of the result at resolved n3. 

The operation is executed on the conceptual machine 
of FIG. 8 as follows: using the PC register, I-stream 
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Reader 805 generates a descriptor for FADD’s SOP. 
The descriptor is delivered via Descriptor Output 806 
to Memory Signal Generator 812, which forms a mem- 
ory signal from it. The memory signal is delivered via 
Memory Signal Input 813 to Memory 801. Memory 801 5 
then outputs the SOP onto Memory Output 803 and 
I-stream Reader 805 parses the SOP and delivers it to 
SOP Decoder 809. SOP Decoder 809 decodes it to 
produce control signals directing further operations. In 



(1) A third load instruction which loads SUM into a 
register. The register may be one of those which 
contained VALA or VALB. 

(2) An additional integer add arithmetic instruction 
which specifies the register containing SUM and 
the result register as sources for the ALU. 

In CS 10110, SINs may only specify data in Memory 
801, and consequently, the result must be stored in 
Memory 801 at the end of the first operation and re- 



response to these control signals, I stream Reader 805 10 trieved from Memory 801 at the beginning of the next, 
obtains the next syllable, i.e., the Name representing The FORTRAN statement 
VALA as described for the SOP, and delivers the Name SUM = SUM + VALA + VALB 

via Syllable Output 807 to Name Translator 811, Name therefore requires two FADD SINs, one specifying 

Translator 811 resolves the Name to produce a descrip- Names for VALA, VALB, and a location in Memory 

tor specifying the location, length, and type of VALA, 15 801 for the temporary storage of the result, and a second 
and outputs the descriptor to Descriptor Output 806. specifying the temporary location and SUM as the 

Memory Signal Generator 812 receives the descriptor sources of the values to be added and SUM as the loca- 

from Descriptor Output 806, and since the SOP speci- tion at which the result is to be stored. The requirement 

fies an Evaluation operation, outputs a signal on Mem- ' n 10110 that the values operated on in SOPs must 

ory Signal Outut 813 specifying that the value at the 20 alwa y s com e from Memory 801 and that the results be 
location of VALA is to be delivered via Memory Out- returned to Memory 801 has the following conse- 

put 803 to Calculating Unit 815. The operation de- quences: 

scribed for VALA’s Name is repeated with the Name (1) The com P iler must frequently specify areas in 
representing VALB, and Calculating Unit 815 begins Memory 801 to hold intermediate results and cre- 

calculating VALA + VALB. Meanwhile, Name Trans- 25 at ® Names and NTEs s P ec >fying these areas. 



lator 811 resolves the Name representing SUM and 
passes the descriptor for SUM to Memory Signal Gen- 
erator 813, which produces a signal on Memory Signal 
Output 813 specifying that the value on Memory Input 3Q 
817 is to be stored at the location specified in the mem- 
ory signal. When Calculating Unit 815 is finished with 
the calculation, the result is output onto Memory Input 
817 and stored at the location obtained by resolving n3. 
Finally, the PC register in I-stream Reader 805 is set to 35 
specify the location of the next SIN, and the execution 
of that SIN proceeds essentially as just described. 

It is noteworthy here that the transfers specified by 
FADD are from Memory 801 to Calculating Unit 815 



(2) SINs must always contain Names specifying 
sources and destinations of data. These Names 
increase the size of the SINs and their resolution 
and evaluation increases execution time. 

(3) The need for extra Names and NTEs to specify 
storage for intermediate results increases the size of 
Procedures 00602 and Name Tables 10350. 

(4) The need to store the result in Memory 801 at the 
end of one SIN and fetch it from Memory 801 at 
the beginning of the next slows the execution of the 
SIN. 

3. SOPs Specifying an Accumulator 

The present invention improves the digital data sys- 



‘ ^macmg unu era , em of us patent app , ication Ser . No . 26 6,539 by add- 

and then back to Memory 801, not from memory to a 40 ing an accumu i ator . FIG . 9 illustrates this change. The 



: " “7 ; , ' - 40 ing an accumulator. FIG. 9 illustrates this change. The 

register and from a register to memory, as in the con- conceptual machine of the t inventjon in | enera] 

ceptual machines of traditional digital computer sys- rese mbles that of CS 10110, but has an additional regis- 
ters. Of course, the actual operation in CS 10110 does ter> Accumulator 901. The results of any operation 

involve registers in FU 10120 and EU 10122, but the performed by Calculating Unit 815 are retained in Ac- 

manner in which these registers are manipulated cannot 45 cumulator 901. Thus, in the present invention, all SOPs 
be specified in the FADD SIN, and arethusnot par t of specifying operations performed by Calculating Unit 

e mac ine escribed by the FADD SIN. 815 implicitly specify Accumulator 901 as a destination 

. l!^nT Cep machlne described for the result of an oper ation. In addition, an SOP may 

by the SINs of CS 101110 for executing programs writ- specify a i ocation in MEM 801 as a desti nation for the 

ten tn high-level languages are obvious when one com- 50 result of an operation and Accumulator 901 as a source 
e slngc EA PP us fd t0 execu te the FOR- f or a value to be operated on. These new possibilities in 

TRAN statement of the example with the sequence of the present invention are indicated by Calculating Unit 

instructions required to execute the statement in typical 815's inputs and outputs in FIG. 9. Calculating Unit 815 
traditional digital computer systems. However, there is is represented with two outputs instead of the single 
one respect in which the fact that instructions in tradi- 55 output of CS 10110. One output is connected to Accu- 
tional digital computer systems may specify registers is mulator 901 and the other to Memory Input 817, indi- 
advantageous: if the result of one operation is required eating that Calculating Unit 815 can output results to 
as input to the next operation, instructions in traditional both Accumulator 901 and Memory 801. Calculating 
digital computer systems can specify the register con- Unit 815 is further represented with three inputs instead 
taining the results as a source of the input for the next 60 of the two inputs of FIG. 8. The additional input, Result 
operation. The advantages stemming from this capabil- Return 903, is connected to Accumulator 901, indicat- 
ity can be seen by considering the FORTRAN state- ing that Accumulator 901 may be used as a source of 
ment data for Calculating Unit 815. 

SUM = SUM + VALA + V ALB Accumulator 901 of the present invention is a special- 

The execution of this statement in a traditional digital 65 purpose register. It may contain only the results of a 
computer system of the prior art requires only two Calculating Unit 815 operation, is loaded only as a con- 
instructions more than the execution of the first example sequence of a Calculating Unit 815 operation, and may 
statement: serve as a source of data only for Calculating Unit 815. 
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In particular, unlike the general-purpose registers of 
traditional digital computer systems, Accumulator 901 
cannot be loaded from Memory 801 and Accumulator 
901’s contents cannot be output to Memory 801. 

Since SINs in the present invention may specify Ac- 
cumulator 901 as a source for Calculating Unit 815, 
operations that were specified by certain single SINs in 
CS 10110 are now specified by one of a group of SINs. 
For example, in the present invention, there are six 
variants of the FADD SIN: 

(1) FADD nl, n2, n3: This SIN is like the FADD of 
CS 10110, except that the result is retained in Accu- 
mulator 901 in addition to being stored in Memory 
801 at the location obtained by resolving n3. 

(2) FADD. A nl, n2: This SIN adds operands ob- 
tained by evaluating nl and n2 and retains the re- 
sult in Accumulator 901. It does not store the result 
in Memory 801, and thus, no third name is neces- 
sary. 

(3) FADD.M nl, n2: This SIN adds the operand 
obtained by evaluating nl to the contents of Accu- 
mulator 901. The result is retained in Accumulator 
901 and is also stored in Memory 801 at the loca- 
tion obtained by resolving n2. 

(4) FADD2 nl, n2: This SIN adds operands obtained 
by evaluating nl and n2, retains the result in Accu- 
mulator 901, and also stores the result in the loca- 
tion in Memory 801 obtained from the resolution of 
n2. 

(5) FADD2.A nl: This SIN evaluates nl, adds the 
result to the contents of Accumulator 901, and 
retains the result in Accumulator 901. 

(6) FADD2.M nl: This SIN evaluates nl, adds the 
result to the contents of Accumulator 901, retains 
the result in Accumulator 901, and also stores the 
result in the location in Memory 801 obtained from 
the resolution of nl. 

The advantages obtained in the present invention by the 
use of a family of SINs in place of the single SIN of CS 
10110 may be seen by comparing the manner in which 
CS 10110 and the present invention deal with the fol- 
lowing FORTRAN example: 



REAL X, Y, Z, A, B, C 

A = B + C 
X = A + Y + Z 



In CS 10110 as described in U.S. patent application 
Ser. No. 266,539, all of the operations specified in the 
two statements of the above fragment would have been 
performed by FADD SINs. In the second statement, a 
location in Memory 801 would have been required to 
hold the result of Y + Z, and consequently, the compiler 
would have had to generate Names and NTEs not only 
for X, Y, Z, A, B, and C, but also for the temporary, 
which we will call TEMP. Using the names of the vari- 
ables for the Names in the SINs which represent them, 
the SINs in CS 10110 required for the two statements in 
the fragment are the following: 

FADD B,C,A 

(Evaluate B, evaluate C, resolve A, do A + B, and 
store the result in A) 

FADD A, Y, TEMP 

(Evaluate A, Evaluate Y, resolve TEMP, do A + Y, 
and store the result in TEMP) 

FADD Z, TEMP, X 
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(Evaluate Z, Evaluate TEMP, resolve X, do 
X + TEMP, and store the result in X) 

Each of the above SINs contains 4 syllables, and thus 12 
syllables must be fetched to perform the specified oper- 
5 ation. Each of the SINs further specifies that 2 data 
items be fetched from Memory 801 to Calculating Unit 
815 and 1 data item be written from Calculating Unit 
815 to Memory 801. Consequently, 9 memory opera- 
tions are required for the data. Furthermore, in execut- 
10 ing the above SINs, CS 10110 of U.S. patent application 
Ser. No. 266,539 performs six Name Evaluation opera- 
tions and three Name Resolution operations. Each of 
these operations requires information from Name Table 
10350 and Name Table 10350 must have a NTE for each 
15 variable and for TEMP. Finally, storage must be pro- 
vided in Memory 801 for the intermediate results. 

In the present invention, the FORTRAN statements 
in the fragment are executed by the following three 
SINs: 

20 FADD B, C, A 

(Evaluate B, evaluate C, resolve A, do B+C, retain 
the result in Accumulator 901, and store the result 
to A) 

FADD2.A Y 

25 (Evaluate Y, add Y to the contents of Accumulator 
901, and retain the result in Accumulator 901) 

FADD.M Z, X 

(Evaluate Z, resolve X, add Z to the contents of 
Accumulator 901, retain the result in Accumulator 
30 901, and store the result to X) 

Thus, in the present invention, the SINs contain 9 
instead of 12 syllables, there are 6 instead of 9 fetches of 
data from Memory 801 or stores of data to Memory 801, 
6 instead of 9 Name Resolution or Evaluation opera- 
35 tions, no space is required in Memory 801 for storing 
intermediate results, and no Name is needed to refer to 
storage for intermediate results. Furthermore, if X, Y, 
Z, A, B, and C are local or static data, and may there- 
fore be located by offsets from FP or SDP, their Names 
40 will be Immediate Names 209 in the present invention, 
there will be no NTEs 307 for the Names, and the Name 
Resolution and Evaluation operations can proceed 
without reference to information in Name Table 305. 

4. Implementation of Accumulator 901 
45 In the present embodiment of the present invention, 
Accumulator 901, Memory Input 817, and Result Re- 
turn 903 are implemented by means of Result Reg 27013 
of EU 10122, JPD Bus 10142, and data paths internal to 
EU 10122 which allow the results of one EU 10122 
50 operation to be used as an operand for another EU 
10122 operation respectively. The relationship between 
JPD Bus 10142, Result Reg 27013, and MEM 10112 
may be seen in FIG. 270 of U.S. patent application Ser. 
No. 266,539; the data paths internal to EU 10122 may be 
55 seen in FIGS. 256 and 257 of #FHP_SPEC. Transfer 
of data from Result Reg. 27013 to MEM 10122 via JPD 
Bus 10142 is under control of FU 10120 microcode, and 
the use of data from Result Reg 27013 as an operand in 
EU 10122 is under control of EU 10122 microcode. 
60 Thus, it was physically possible in CS 10110 as de- 
scribed in U.S. patent application Ser. No. 266,539 to 
retain results of an operation in Result Reg 27013 while 
writing it to MEM 10112 and to then use the contents of 
Result Reg 27013 as an operand for EU 10122, but the 
65 SINs available in CS 10110 did not specify such opera- 
tions. The SINs of the present invention, however, can 
specify Accumulator 901 as described above, and all 
that is required to implement them is new opcodes and 
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FU 10120 and EU 10122 microcode responsive to these 
new opcodes. Examples of such microcode are pro- 
vided in CSL.DISP 2 and ACCUMULATION_ EN- 

TRIES of Appendix A. 

E. Call SINs and the Return SIN 

In both CS 10110 of U.S. patent application Ser. No. 
266,539 and the present invention, the execution of a 
Call SIN suspends the execution of the Procedure 00602 
containing the Call SIN (the calling Procedure 00602) 10 
at the point of the Call SIN and commences an execu- 
tion of another Procedure 00602 (the called Procedure 
00602) specified in the Call SIN. While a called Proce- 
dure 00602 is executing, it may use data from calling 
Procedure 00602. Such data is called arguments, and the 15 
Call SIN specifies which data is to be used for a given 
execution of called Procedure 00602. The execution of 
a Return SIN terminates an execution of called Proce- 
dure 00602 containing the Return SIN and resumes the 
execution of calling Procedure 00602 whose execution 20 
was suspended by execution of the Call SIN. In terms of 
the Conceptual Machine of FIG. 8, the Call SIN sets 
registers PC, K, SIP, SP, FP, SDP, PBP, and NTP of 
FIG. 8 to values appropriate for called Procedure 00602 
and the Return SIN resets those registers to the values 25 
they had at the time of the execution of the Call SIN. As 
may be seen from the above, a Call SIN must do five 
things: 

It must save the contents of the registers of the con- 
ceptual S-language machine. 30 

It must provide means by which called Procedure 
00602 can locate the data used as arguments in the 
Call SIN. 

It must locate called Procedure 00602. 

It set the registers of the conceptual S-language ma- 35 
chine to the values required for the execution of 
called Procedure 00602. 

It must allocate storage in Memory 801 for the execu- 
tion of called Procedure 00602. 

It must begin execution of called Procedure 00602. 40 

The Return SIN must do two things: 

It must locate the register values for calling Proce- 
dure 00602 saved by the Call SIN. 

It must set the registers in the conceptual S-language 
machine from these values. 45 

In CS 10110 and the present invention, the Call SINs 
employ a Macro Stack (MAS) 00502 to save the register 
values for calling Procedure 00602, to provide called 
Procedure 00602 with access to the arguments specified 
in the Call SIN, and to provide the memory space re- 50 
quired for called Procedure 00602’s execution. MAS 
00502 is made up of frames. Each frame contains state 
for an execution of a Procedure 00602. The topmost 
frame in MAS 00502 is that of Procedure 00602 cur- 
rently being executed; the preceding frame in MAS 55 
00502 is that of Procedure 00602 which was the caller of 
Procedure 00602 currently being executed, the frame 
preceding that frame is that of the caller of the caller, 
and so on. When a Call SIN is executed, it creates a new 
frame for called Procedure 00602 at the top of MAS 60 
00502, and when a Return SIN is executed, it makes the 
preceding frame, which is that belonging to calling 
Procedure 00602 which called Procedure 00602 in 
which the Return SIN was executed, into the top frame 
of MAS 00502. While all Calls in CS 10110 and the 65 
present invention function logically as described above, 
certain characteristics of CS 10110 and the present in- 
vention make the execution of certain Call SINs much 
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more complex that the execution of other Call SINs. 
The first of these characteristics is that more state must 
be changed in some Call SINs than in others. In CS 
10110 and the present invention, a Procedure 00602 has 
associated with it a Procedure Environment Descriptor 
(PED). A Procedure 00602’s PED contains the follow- 
ing: 

NTP, A pointer to Name Table 10350 which contains 
NTEs for Procedure 00602’s Names. 

SIP, an identifier for the S-interpreter required to 
execute Procedure 00602’s SOPs. 

SDPP, a pointer which may be resolved to obtain the 
location of static data used by an execution of Pro- 
cedure 00602. 

PBP, a pointer to a location used as a base from 
which to calculate locations in Procedure 00602. 

On a call, the SIP register in the conceptual S-lan- 
guage machine is set from SIP, the SDP register is set 
from a pointer obtained by resolving the pointer in 
SDPP, and the PBP register is set from PBP. 

If a calling Procedure 00602 and a called Procedure 
00602 share a PED, the call need not change the values 
contained in the SIP, SDP, and PBP registers. All that 
is required is that FP and SP be set to specify the proper 
locations in called Procedure 00602’s frame and PC be 
set to the location of the first of called Procedure 
00602’s SINs. When calling Procedure 00602 and called 
Procedure 00602 do not share a PED, called Procedure 
00602’s PED must be located and the SIP, SDP, and 
PBP registers must be set to values obtained from the 
PED. The amount of time required to execute a Return 
SIN is similarly dependent upon the number of concep- 
tual S-language machine registers which must be reset. 
The second of these characteristics is the access control 
system of CS 10110 and the present invention. As ex- 
plained in detail in 4.C of U.S. Pat. Ser. No. 266,539, in 
CS 10110 and the present invention, Procedures 00602 
are executed by entities called Subjects. A Procedure 
00602 may access data only if an Access Control List 
associated with the object containing the data allows 
the Subject executing Procedure 00602 to have the kind 
of access to the data in the object required to perform 
the operation specified by the SIN in Procedure 00602 
currently being executed. Each Procedure Object 
00608 has associated with it a Domain of Execution 
attribute. When a Subject is executing a Procedure 
00602 contained in that Procedure Object 00602, the 
Domain of Execution attribute is one component of the 
Subject. Thus, when a Call SIN invokes a Procedure 
00602 contained in a Procedure Object 00608 with a 
different Domain of Execution attribute from that pos- 
sessed by calling Procedure 00602’s Procedure Object 
00608, the Subject executing called Procedure 00602 
changes. Such a call is termed a Cross-domain Call. 
Because a Cross-domain Call changes the Subject, the 
Called Procedure 00602 has no access to MAS Object 
(MASO) 46703 containing calling Procedure 00602’s 
stack frame and the stack frame for called Procedure 
00602 must be constructed in a MASO 46703 to which 
the new Subject has access. In order to construct the 
stack frame, the Call SIN must locate MASO 46703 for 
the new stack frame and copy state from MASO 46703 
containing calling Procedure 00602’s stack frame over 
to MASO 46703 containing the new stack frame. On a 
return from such a Call, the subject similarly changes 
and the Return SIN must locate MASO 46703 contain- 
ing calling Procedure 00602’s stack frame. The change 
of the Subject and the transitions from one object to 
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another and back in Cross-domain Call are handled by 
KOS microcode components. The state required to 
locate the proper MASO 46703 is stored on a separate 
stack accessible only to KOS. This stack is contained in 
SS Object 10336. 5 

1. Calls and Returns in CS 101 10 

Call and Return in CS 10110 is described in detail in 
Section 4.E.d of U.S. patent application Ser. No. 
266,539. In CS 10110, SS Object 10336 and two Call 
SINs were used to deal with the differing degrees of 10 
state manipulation required in Call and Return opera- 
tions. The two SINs were the Mediated Call SIN and 
the Neighborhood Call SIN. Mediated Call SINs were 
used for Calls involving Procedures 00602 which did 
not share PEDs; consequently, Mediated Call Sins set 15 
PC, K, SIP, SP, FP, SDP, PBP, and NTP in the con- 
ceptual S-language machine. Neighborhood Call SINs 
were used for Calls involving Procedures 00602 which 
did share PEDs; consequently, Neighborhood Call 
SINs set only PC, SP, and FP. However, this optimiza- 20 
tion was not possible with regard to the Return SIN. It 
was possible for a given Procedure 00602 to be called 
by both Mediated Call SINs and Neighborhood Call 
SINs, and the Return SIN therefore had to determine 
which Call SIN had called Procedure 00602 and in the 25 
case of the Mediated Call SIN, whether the Return SIN 
had to locate a new PED, a new Procedure Object 
00608, or a new stack. The Mediated Call SIN stored 
this information in SS Object 10336 and the Return SIN 
examined this information to determine what actions it 30 
had to perform. Consequently, SS Object 10336 was 
involved in all Mediated Calls and in all Returns. 

2. Calls and Returns in the Present Invention 

In the present invention, there are one Mediated Call 
SIN and two Neighborhood Call SINs. The Mediated 35 
Call SIN is called GCALL. For the present discussion, 
it may be specified as follows: 

GCALL nl, [n2, n3, . . . nm] 

SOP 701 for the GCALL SIN contains the opcode 40 
and, in OM Field 705, the number of arguments. The 
first Operand Syllable 707 is a Name specifying Proce- 
dure 00602 being called; when the Name is evaluated, it 
yields a pointer specifying information from which 
called Procedure 00602 may be located. The remaining 45 
Names specify arguments used in the Call. Resolution 
of these Names and descriptor-to-pointer conversion 
yields pointers to the arguments. Since all Operand 
Syllables 707 have 16 bits, GCALL does not set the K 
register of the conceptual S-langauge machine; other- 50 
wise, like Mediated Call, it sets PC, SIP, SP, FP, SDP, 
PBP, and NTP. 

The Neighborhood Call SIN may be specified for the 
present discussion like this: 

NCALL litl, [n2, n3, . . . nm] 55 

SOP 701 for the NCALL SIN also contains the op- 
code in Opcode Field 703 and the number of arguments 
in OM Field 705. The first Operand Syllable 707 is an 
I-stream Literal 709 which, when multiplied by 16, 
specifies the offset of called Procedure 00602 from the 60 
NCALL SIN. When this value is multiplied by 8 and 
added to PC, the result is the beginning of called Proce- 
dure 00602. The remaining Operand Syllables 707 are 
Names specifying arguments, as in GCALL. 

I-stream Literals 709 are 16 bits long, and therefore 65 
cannot specify a Procedure 00602 which is located 
more than 2** 15-1 bytes from the NCALL SIN. When 
two Procedures 00602 share a PED but are located too 
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far apart for NCALL, the Neighborhood Call by Name 
SIN is used. It is specified as follows: 

NCALLN nl, [n2, n3, . . . nm] 
nl is an Immediate Name 209 or a Table Name 201 
which resolves to a location which is a displacement 
from PBP. The specified location is the beginning of 
Called Procedures 00602. The remaining Names specify 
arguments, as in the other Call SINs. Both NCALL and 
NCALLN set only PC, SP, and FP. 

As explained in detail in U.S. patent application Ser. 
No. 266,539 4.E.d.7, a call may also result in CS 10110 
and the present invention when microcode executing on 
JP 10114 requires assistance from programs written in 
high-level languages. In terms of the S-language con- 
ceptual machine, microcode to software calls behave 
like calls made by the GCALL SIN. 

As in CS 10110, there is a single Return SIN: 

RTN 

The RTN SIN has no Operand Syllables 707. The 
conceptual S langauge machine registers changed by 
RTN depends on the number changed in the call. 

3. Operation of Call and Return SINs 
As described above, the Call and Return SINs use 
data contained in Procedure Objects and manipulate 
stack frames. The following discussion first presents 
Procedure Objects and Stack Frames in the present 
invention and then discloses the operation of Call and 
Return SINs with reference to these Procedure Objects 
and Stack Frames. 

a. Procedure Objects 1001 

FIG. 10 presents Procedure Object 1001 of the pres- 
ent invention. FIG. 10 may be compared with FIG. 472 
of U.S. patent application Ser. No. 266,539, which 
shows Procedure Object 00608 of CS 10110. As may be 
seen from the comparison. Procedure Object 1001 is 
similar in its basic parts to Procedure Object 00608: 
both contain Literals 30301, PEDs 10348, Code 10344, 
Static Data Prototype 30317, Name Tables 10350, and 
Binder Area 30323. The differences are to be found in 
Header 1003, Gates 1009, Entry Descriptor AREA 
1007, PED 1013, Procedures 1016, and Argument In- 
formation Arrays 1017. Header 1003 still contains Gate 
Limit 47203 specifying the number of Gates 1009 in 
Procedure Object 1001, but no longer contains AIA 
Offset 47203 specifying the location of argument infor- 
mation arrays. As will be seen, this information is at 
other locations in Procedure Object 1001. Entry De- 
scriptor Area 1007 contains Entry Descriptors 1011. 
These in turn contain information required to locate 
Procedures 1016. A Gate in Procedure Object 1001 is 
simply as Entry Descriptor 1009 which is within the 
number of Entry Descriptors 1011 specified by the 
value of Gate Limit Field 47203. A calling Procedure 
1016 in one Procedure Object 1001 may invoke a called 
Procedure 1016 in another Procedure Object 1001 only 
if called Procedure 1016’s Entry Descriptor 1011 is in 
Gates 1009. 

The function of PEDs 10348 has already been de- 
scribed; their structure in the present invention will be 
described later. Code 10344 contains Procedures 1016. 
These differ from Procedures 00602 in one respect only: 
the first 16 bits of a Procedure 1016 is ADS Field 1015. 
ADS Field 1015 contains a 16-bit unsigned value which, 
when multiplied by 128, specifies the amount of local 
storage initially required for Procedure 1016’s local 
data. Argument Information Arrays 1017, finally, are a 
group of individual Argument Information Arrays 
rather than a single large Argument Information Array. 
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Turning now to FIG. 11, FIG. 11 gives detailed rep- 
resentations of Entry Descriptors 1011 and a PED 1013. 
There are two kinds of Entry Descriptors 1011: Termi- 
nal Entry Descriptors 1101, which contain the informa- 
tion required to locate a Procedure 1016, its PED 1013, 5 
and its Argument Information Array 10352, and Indi- 
rect Entry Descriptors 1113, which contain a resolved 
object relative pointer specifying the location of an- 
other pointer which in turn specifies the location of 
another Entry Descriptor 1011. Terminal Entry De- 10 
scriptor 1101 contains the following fields: 

CSO Field 1103: When the value of this Field is 
added to the base location contained in PBP, the 
result is the location of Field ADS 1015 of Proce- 
dure 1016 specified by Terminal Entry Descriptor 15 
1101 . 

Version Field 1105 and TY Field 1107 specify the 
version of Terminal Entry Descriptor 1101 and 
identify it as a Terminal Entry Descriptor. 

PED PTR 1109 is a resolved object-relative pointer 20 

specifying the location of PED 1013 for Procedure 
1016 specified by Terminal Entry Descriptor 1101. 

AIA PTR 1111 is a resolved object-relative pointer 

specifying the location of an Argument Informa- 
tion Array in Argument Information Arrays 1017 25 
for Procedure 1016. If Procedure 1016 has no Ar- 
gument Information Array, the pointer is a null 
pointer. 

The fields of Indirect Entry Descriptor 1113 differ 
from those of Terminal Entry Descriptor 1101 as fol- 30 
lows: The first 32 bits contain LP PTR 1115, a re- 
solved Object Relative pointer specifying the location 
of a pointer which, when resolved, yields the location 
of another Entry Descriptor 1011. Version Field 1105 
and TY Field 1107 specify the version of Indirect Entry 35 
Descriptor 1113 and that Indirect Entry Descriptor 
1113 is an Indirect Entry Descriptor. The last 32 bits of 
Indirect Entry Descriptor 1113 contain AIA PTR 
1111, which has the same function as in Terminal Entry 
Descriptor 1101. 40 

PED 1013 of the present invention contains informa- 
tion required for the execution of Procedures 00602 
sharing PED 1013, and thus has the same function as 
PED 30303 of CS 10110, described in 3.B.a of U.S. 
patent application Ser. No. 266,539, but certain fields 45 
have been eliminated and others are at different loca- 
tions. SEPP Field 30316 and K Field 30305 have been 
eliminated. The latter field specified the syllable size of 
operand syllables in Procedures 00602 sharing PED 
30303, and is thus no longer required in the present 50 
invention. The remaining fields are the following: 

Version Field and TY Fields 1107 specify the version 
of PED 1013 and that the data item following TY 
Field 1107 is a PED 1013. 

Three Fields are identical to their equivalents in PED 55 
30303: LN Field 30307 specifies the location of the 
last NTE in Name Table 305 associated with PED 
1013, SIP Field 30309 specifies the S-interpeter 
used by SINs in Procedures 1016 sharing PED 
1013, and SDPP Field 30313 contains a pointer 60 
whose resolution yields the location of static data 
used by an execution of a Procedure 1016 sharing 
PED 1013. 

PBP PTR Field 1115 contains a resolved object- 
relative pointer specifying PBP for Procedures 65 
1016 sharing PED 1013. 

NTP PTR Field 1117 contains a resolved object- 

relative pointer specifying NTP, the beginning of 
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Name Table 305 for Procedures 1016 sharing Ped 

1013. 

The effects of the changes to Procedure Objects 
00608 of CS 10110 in Procedure Objects 1016 may b_ 
summarized as follows: First, the addition of ADS Field 
1015 makes it possible to allocate local storage for a 
Procedure 1016 without reference to Procedure 1016’s 
Terminal Entry Descriptor 1101. Second, the AIA for a 
Procedure 1016 may be located from Terminal Entry 
Descriptor 1101 instead of from Header 1003. Third, a 
Procedure 1016’s Entry Descriptor 1101 is located at 
the Gate for that Procedure 1016. The effect of all of 
these changes is to reduce the number of memory refer- 
ences required to perform a CALL SIN in the present 
invention. 

b. MAS Frame 1201 

In CS 10110 and in the present invention, each execu- 
tion of a Procedure has associated with it a frame in a 
MAS Object 46703. MAS Frame 46709 of CS 10110 is 
illustrated in FIG. 469 of U.S. patent application Ser. 
No. 266,539 and described in Section 4.E.d.2.c.c; FIG. 
12 illustrates MAS Frame 1201 of the present invention. 
Like MAS Frames 46709, MAS Frame 1201 contains an 
area for local storage, an area for linkage pointers for 
arguments, and areas for information used during exe- 
cution of a Return SIN. However, the complexity of the 
latter areas has been greatly reduced. 

A MAS Frame 1201 may be either an NCALL 
Frame 1239 or a GCALL Frame 1241. NCALL 
Frames 1239 are produced by the execution of NCALL 
and NCALLN SINs; GCALL Frames 1241 are pro- 
duced by the execution of GCALL SINs. As may be 
seen from FIG. 12, a GCALL Frame 1241 has the same 
fields as an NCALL Frame 1239, and in addition con- 
tains ESSA 1237. Beginning at the top of NCALL 
Frame 1239, there is Local Storage 10420, containing 
storage used for variables contained in Procedure 1016 
called by the Call SIN. Next comes Basic State Area 
(BSA) 1215, which identifies the kind of Call SIN 
which created MAS Frame 1201 and contains the state 
required for a return to a calling Procedure 1016 which 
shares a PED 1013 with the called Procedure 1016. 
BSA 1215 has the following fields: 

OLD FP PTR Field 1205 contains an object-rela- 

tive pointer specifying the location of FP in MAS 
Frame 1201 belonging to calling Procedure 1016. 

NF — BOT PTR Field 1207 contains an object-rela- 

tive pointer specifying the bottom of OS Area 1219 
in MAS Frame 1201. In NCALL Frames 1239, this 
is the bottom of MAS Frame 1201; in GCALL 
Frames 1241, it is the top of ESSA 1237. 

OLD PC OFF Field 1207 contains the offset from 

PBP of the SIN at which calling Procedure 1016 is 
to resume execution. This Field is 30 bits long. 

Flags _1 Field 1211 and Flags _2 Field 1213 contain 
flags set by the Call SINs and used by the Return 
SIN to determine the kind of Call SIN which made 
MAS Frame 1201. These flags will be explained in 
more detail below. 

Flags _1 Field 1211 contains two bits. The left bit 
specifies when set that Flags_2 Field 1213 is being used 
in this MAS Frame 1201. The right bit specifies the kind 
of MAS Frame 1201. If the bit is set, MAS Frame 1201 
is a GCALL Frame 1241; otherwise, MAS Frame 1201 
is an NCALL Frame 1239. NCALL sets these two bits 
to 00 and GCALL and microcode-to-software cell sets 
them to 1 1. In Flags_2 Field 1213, four bits are impor- 
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tant for this discussion. The bits are numbered from the 
left, with the leftmost bit as bit 0: 

Bit 27, Microcode-to-software Call Flag; When this 
bit is set, the call which created GCALL Frame 
1241 was a microcode-to-software call. 5 

Bit 28, Cross Domain Entry Flag: When this bit is set, 
the call which created GCALL Frame 1241 was 
the first of a sequence of calls to Procedures 1016 
having the same Domain of Execution. 

Bit 29, Cross Domain Exit Flag: When this bit is set, 10 
the call which created GCALL Frame 1241 was 
the last of a sequence of calls to Procedures 1016 
having the same Domain of Execution. 

Bit 30: Non-local GOTO Flag: Non-local GOTOs 
are explained in detail in U.S patent application 15 
Ser. No. 266,539 4.E.d.8.b.b. When this bit is set, it 
indicates that a non-local GOTO involving this 
MAS Frame 1201 is currently being executed. 

The next portion of MAS Frame 1201 is Linkage 
Pointers 1217. There is one linkage pointer in Linkage 2 
Pointers 1217 for each Name specifying an argument in 
the Call SIN which created MAS Frame 1201. The Call 
SINs reverse the order of arguments in the high-level 
langauge procedure invocations corresponding to the 
Call SINs, and when the Call SIN creates MAS Frame 
1201, it places the linkage pointer to the argument cor- 
responding to the first Name specifying an argument in 
the Call SIN immediately above OS Area 1219, the next 
linkage pointer above the first and so on. Consequently, 
the order of argument pointers in Linkage Pointers 1217 
relative to FP corresponds to the order of arguments in 
the high-level langauge procedure invocation corre- 
sponding to the Call SIN. 

OS Area 1219 contains offsets from FP of informa- }5 
tion used by KOS to handle non-local GOTOs and 
conditions. These offsets correspond to Catch List Off 
46927, Clean Up List Off 46925, and Frame Top Off 
46921 of FIG. 469. For details, see the description of 
these fields in U.S. patent application Ser. No. 266,539 4Q 
4.E.d.l.c.c. 

Extended State Save Area (ESSA) 1237 is present 
only in GCALL Frames 1241. It contains the additional 
saved state required for returns from Procedures 1016 
called by GCALL SINs. Initial Target Field 1221 con- 45 
tains a copy of the resolved pointer to called Procedure 
1016 obtained from the evaluation of nl in the GCALL 
SIN. It is present in GCALL Frame 1241 to enable a 
debugger to determine which Procedure 1016 was 
called by the GCALL SIN which produced GCALL 50 
Frame 1241. The remaining fields in ESSA 1237 contain 
saved state from the execution of calling Procedure 
1016: 

OLD SDP Field 1223 contains a resolved pointer 

specifying SDP for the execution of calling Proce- 55 

dure 1016. 

OLD_PBP Field 1225 contains a resolved pointer 
specifying PBP for the execution of calling Proce- 
dure 1016. 

TY Field 1227 indicates that the area following it is 60 
an ESSA 1237, and Ver Field 1229 indicates the 
version of ESSA 1237. 

DIA 1231 is an integer which corresponds to a value 
of SIP 30309 and specifies the S-language required 
by calling Procedure 1016’s SINs. 65 

OLD_SP_PTR 1233 is a resolved object-relative 
pointer specifying the location of the topmost bit in 
calling Procedure 1016’s MAS Frame 1201. 
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OLD__NT_PTR, finally, is a resolved object-rela- 
tive pointer specifying the location of Procedure 
1016’s Name Table 305. 

The chief difference between MAS Frame 1201 of 
the present invention and MAS Frame 46709 of CS 
10110 are the following: the information required to 
return from a NCALL or NCALLN has been separated 
from the information required to return from GCALL; 
the kind of MAS Frame 1201 and the kind of Call SIN 
which created it are specified by flags in BSA 1217; 
NCALL Frames 1239 and GCALL Frames 1241 are 
identical execept for the presence of ESSA 1237 in the 
latter. 

4. Operation of the NCALL and NCALLN SINs 

When a Call is made by an NCALL or NCALLN 
SIN, the following operations are performed by the FU 
10120 microcode which interprets these SINs: 

The current PC, current FP, current PBP, and cur- 
rent SP are saved in FU 10120 registers. 

The number of arguments in the Call is obtained from 
OM Field 705 of SOP 701. 

The next Operand Syllable 707 is parsed. In the case 
of NCALL, Operand Syllable 707 is an I-stream 
Literal 709. Its value is multiplied by 16 and added 
to the current PC value, PC specifies the location 
of ADS Field 1015 of called Procedure 1016. In the 
case of NCALLN, Operand Syllable 707 is a Name 
specifying the location of ADS Field 1015 of Pro- 
cedure 1016. The Name is resolved to obtain a 
descriptor for that location and PC is set from the 
descriptor. 

SP is incremented by SP MOD 128 and the resulting 
value, which is the location of the bottom of the 
new NCALL Frame 1239, is saved. 

OS Area 1219 is added to new MAS Frame 1201 and 
SP is incremented by 128. 

Beginning with the first Name representing an argu- 
ment in the NCall SIN, for each Name, the Name 
is resolved, the resulting descriptor is converted to 
a pointer, the pointer is placed on NCALL Frame 
1239, and SP is incremented by 128. At the end of 
these operations, Linkage Pointers 1217 are on new 
MAS FRame 1201. 

BSA 1215 is placed on NCALL Frame 1239 and SP 
is incremented by 128. Its Fields are set as follows: 

OLD FP PTR 1025 is set to the value of saved 

FP, that is, the value of FP in Caller’s Frame 1243; 

NF BOT PTR 1207 is set to the saved value 

which specified the bottom of NCALL Frame 
1239; OLD_PC_OFF 1209 is set to specify the 

SIN following the CALL SIN; Flags 1 1211 is set 

to 00. 

FP is set to the current value of SP. 

The I-stream Literal in ADS Field 1015 is parsed, its 
value is multiplied by 128, and that number of bits 
is allocated as Local Storage 10420, and SP is in- 
cremented to point to the top of Local Storage 
10420. 

The first SIN of called Procedure 1016 is executed. 

Since calling Procedure 1016 and called Procedure 
1016 share a PED 1013, NCALL and NCALLN need 
not change or save NTP, PBP, SIP, or SDP. 

5. Operation of the GCALL SIN 

The operation of the GCALL SIN differs in four 
respects from that of the NCALL or NCALLN SINs: 
GCALL must locate a Terminal Entry Descriptor 1101 
for called Procedure 1016, it must create an ESSA 1237 
on called Procedure 1016’s GCALL Frame 1241, and it 
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must locate called Procedure 1016’s PED 1013 and 
reset NTP, PBP, SIP, and SDP from values contained 
in called Procedure 1016’s PED 1013, 

After determining the number of arguments and sav- 
ing FP, PC, and PBP as described for NCALL, FU 5 
10120 microcode executing GCALL must locate Ter- 
minal Entry Descriptor 1101 for called Procedure 1016. 

The location of Terminal Entry Descriptor 1101 com- 
mences with the evaluation of nl of GCALL. The eval- 
uation of the Name yields a pointer containing the loca- 10 
tion of an Entry Descriptor 1011. If Entry Descriptor 
1011 is not in the same Procedure Object 1001 as calling 
Procedure 1016, FU 10120 microcode first checks 
whether the Subject executing calling Procedure 1016 
has Execute access to Procedure object 1001 containing 15 
called Procedure 1016. If not, the Call aborts. If the 
Subject does have Execute access, FU 10120 microcode 
checks the Domain of Execution Attribute of Proce- 
dure Object 1001 containing called Procedure 1016. If 
the Domain of Execution Attribute is different from 20 
that of Procedure Object 1001 containing calling Proce- 
dure 1016, the Call is a Cross-domain Call, described 
below. If the Call is not a cross-domain Call, FU Micro- 
code examines Gate Limit Field 47203 to determine 
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most bit of Flags 1 is set to 1 and bit 29 of Flags 2 is 

set to 1, indicating a cross-domain exit. Then it stores a 
resolved UID Pointer to the top of BSA 1215 in Secure 
Stack Object 10336. The next step is examining 
AIA — PTR Field 1111 of Terminal Entry Descriptor 
1111 to see whether an AIA Array for Procedure 1016 
is present in Argument Information Arrays 1017. If it is, 
FU 10120 GCALL microcode performs a Trojan Horse 
Argument Check, as described in U.S. patent applica- 
tion Ser. No. 266,539 4.E.d.5.e.e. Then KOS microcode 
invoked by GCALL locates MAS Object 46703 be- 
longing to the domain specified by the Domain of Exe- 
cution Attribute of Procedure Object 1001 containing 
called Procedure 1016 and sets the SP register to the 
location of the top of MAS Stack 00502 in that object. 
The next step is to copy ESSA 1237, Linkage Pointers 
1217, and BSA 1215 into that MAS Object 46703 above 
the location specified by SP, incrementing SP as it does 
so. The manner in which MAS Object 46703 is located 
is described in detail in U.S. patent application Ser. No. 
266,539 4.E.d.5.e.e. On the copying operation, bit 28 of 
Flags — 2 is set to 1, indicating a cross-domain entrance. 
After the copying operation has been completed, 
GCALL microcode completes the call as described 
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whether Entry Descriptor 1011 is a Gate. If it is not, the 25 above. 

Call aborts. Otherwise, FU 10120 microcode executing 
GCALL examines TY Field 1107 to determine whether 
Entry Descriptor 1011 is a Terminal Entry Descriptor 
1101 or an Indirect Entry Descriptor 1113. If it is the 
latter, FU 10120 microcode obtains the location of a 30 
linkage pointer to another Entry Descriptor 1101 from 
LP PTR Field 1115. It then performs a pointer resolu- 
tion operation on the linkage pointer and uses the result- 
ing resolved pointer to locate the new Entry Descriptor 
1011. If Entry Descriptor 1011 is another Indirect 35 
Entry Descriptor 1113, the microcode repeats the oper- 
ation just described. 

If Entry Descriptor 1011 is a Terminal Entry De- 
scriptor 1 101, FU 10120 microcode begins constructing 
a GCALL Frame 1241. It first increments SP by SP 40 
MOD 128 and then builds ESSA 1237 as follows: It first 
sets TY Field 1227 and VER Field 1229 to the proper 
values and then saves an object-relative pointer to the 
top of Caller’s Frame 1243 in OLD_SP_PTR 12 33 
and an object-relative pointer to Name Table 305 in 45 
OLD — NT — PTR 1235. Thereupon it copies current 

PBP into OLD PBP 1225, current SDP into 

OLD—SDP 1223, and the pointer obtained from evalu- 
ating nl of GCALL into Initial Target 1221. At the end , 

of the operation, SP is set to point to the top of ESSA 50 Frame 1201. 

Itic OCall then adds Linkage Pointers 1217 and BSA In the case of non-cross-domain GCALL, the right- 
1215 as described for NCALL, except that the right- most bit of Flags_ 1 Field 1213 is set to 1. Since calling 

mast bit of Flags 1 Field 1211 is set to 1. Procedure 1016 and called Procedure 1016 do not share 

D J? IS F V, *®“® ™crocode uses the value in a PED in this case, FU 10120 Return microcode must 

rtzu riK Field 1109 of Terminal Entry Descriptor 55 not only restore FP, SP, and PC, but also PBP SDP 
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6. Operation of the Return SIN 

The manner in which the Return SIN operates de- 
pends upon whether called Procedure 1016 was called 
by a NCALL or NCALLN SIN or by a GCALL SIN, 
and in the latter case, upon whether the call was a cross- 
domain call. As indicated above, the type of call which 
created a given MAS Frame 1201 is specified in 
Flags. — 1 Field 1211 and Flags_2 Field 1213 of BSA 
1215. Consequently, the manner of operation of the 

Return SIN is determined by the settings of Flags 1 

Field 1211 and Flags_2 Field 1213. 

Beginning with returns from Procedures 1016 in- 
voked with NCALL or NCALLN, in this case, the 
rightmost bit of Flags 1 Field 1211 is set to 0 and MAS 
Frame 1201 is an NCALL Frame 1239. Since the state 
specified by PED 1013 does not change on an NCALL, 
all that FU 10120 Return microcode which executes the 
Return SIN need do is set FP to the value contained in 
OLD — FP_ PTR Field 1205, PC to the value specified 

in OLD PC .OFF Field 1209, and SP to the value 

specified in NF BOT_PTR 1207. Thus, at the end of 

the Return operation, PC specifies the SIN following 
the NCALL or NCALLN SIN in calling Procedure 
1016 and FP specifies calling Procedure 1016’s MAS 

r? ■* 



1101 to locate PED 1013 for called Procedure 1016 and 
sets PBP, NTP, SIP, and SDP from PBP_PTR Field 
1115, NTP — PTR Field 1117, SIP Field 30309, and 
SDPP Field 30313 respectively. Finally, FU 10120 mi- 
crocode uses the value in CSO Field 1103 to set PC to 
the location of ADS Field 1015 in called Procedure 
1016, fetch the I-stream Literal 709 in that field, and 
complete GCALL Frame 1241 as explained in the dis- 
cussion of NCALL. Thereupon, FU 10120 microcode 
executes the first SIN of Called Procedure 1016. 

On a Cross-domain Call, FU 10120 microcode first 
constructs ESSA 1237, Linkage Pointers 1217, and 
BSA 1215 as described above. In BSA 1215, the right- 
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SIP , and NTP . As shown above, the values required to 
do this are contained in ESSA 1237. Hence, FU 10120 
Return Microcode restores FP from BSA 1215 and then 

uses the value in NF_ BOT PTR Field 1207 to locate 

ESSA 1237. Having found ESSA 1237, it restores SIP 

from DIA 1231, NTP from OLD NTP PTR 1235, 

PBP from OLD PBP 1225, SDP from OLD_SDP 
1223, and SP from OLD_SP_PTR 1223. Then FU 
10120 Return microcode restores PC by adding the 
value contained in OLD_PC_OFF 1209 to PBP and 
finishes as described above. 

In the case of cross-domain GCALL, finally, the 
leftmost bit of Flags _1 Field 1213 is set to 1 and both 
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bits 29 and 30 of Flags 2 Field 1213 are set to 1 In this 
case, FU 10120 Return microcode invokes KOS micro- 
code, which restores SP from the value which cross- 
domain GCALL stored in Secure Stack Object 10336. 
Thereupon, the execution of the Return SIN continues 
as described above for returns from non-cross-domain 
GCALLs. 

7. Summary of Improvements in Calls and Returns in 
the Present Invention 

The improvements in calls and returns resulting from 
the changes in PO 1016 and MAS Frame 1201 in the 
present invention may be readily apprehended by com- 
paring the description of calls and returns in U.S. patent 
application Ser. No. 266,539 4.E.d with the above de- 
scription of the operations in the present invention. The 
improvements may be summarized as follows: 

The use of Entry Descriptors 1011 in Gates 1009 and 

the addition of AIA PTR 1111 to Terminal Entry 

Descriptor 1101 have reduced the amount of time 
required to locate a called Procedure 1016 and 
determine whether a call is valid. 

The addition of ADS Field 1015 to Procedure 1016 
allows NCALL and NCALLN to allocate Local 
Storage 10420 without reference to Terminal 
Entry Descriptor 1101. 

Since NCALL and NCALLN need not refer to Ter- 
minal Entry Descriptor 1101, NCALL can reset 
PC directly from the I-stream Literal 709 following 
the NCALL SOP 701 and NCALLN can reset PC 
after resolving nl. 

Making GCALL Frame 1241 an extension of 
NCALL Frame 1239 allows all Return SINs to 
begin in the same fashion. 

Placing flags indicating the kind of MAS Frame 1201 
and the state which must be restored by a return 
from NCALL or NCALLN in BSA 1215 makes it 
possible for Return SINS in Procedures 1016 called 
by NCALL or NCALLN to complete the return 
simply by restoring state from BSA 1215. 

Placing flags indicating whether a GCALL is a cross- 
domain call in BSA 1215 and the state which must 
be restored in a non-cross-domain call makes it 
possible for Return SINs in Procedures 1016 called 
by non-cross-domain GCALL to complete the 
return by restoring state from BSA 1215 and ESS A 
1237. Only returns from cross-domain GCALL 
involve SS Object 10336. 

In addition, calls and returns of the present invention 
benefit from other improvements already discussed. In 
CS 10110, literal syllables in the Call SINs specified the 
number of arguments; in the present invention, the last 
8 bits of the SOP specifies the number of arguments. In 
CS 10110, there was only one kind of Name, and all 
arguments were specified by these Names; in the pres- 
ent invention, arguments may be specified by either 
Table Names or Immediate Names. In CS 10110, fi- 
nally, different Procedures 00602 could have operand 
syllables with different sizes, and a Mediated Call SIN 
therefore had to first save K, the value representing 
syllable size, for calling Procedure 00602, and then set 
K to its value for called Procedure 00602. A Return 



F. Linkage Pointer Encachement 

In CS 10110 and the present invention, linkage point- 
ers are pointers to items which cannot be located by 
5 means of displacements from the ABPs. Three large 
classes of items which are located by means of linkage 
pointers are arguments for a Procedure 1016, pointers 
to Entry Descriptors 1011 in different Procedure Ob- 
jects 1001, and static data which is not located in Static 
10 Data Block 46863. As was explained with regard to 
FIG. 12, linkage pointers for arguments are contained in 
Linkage Pointers 1217 in MAS Frame 1201. Since Link- 
age Pointers 1217 are located below FP, Names repre- 
senting argument pointers in Linkage Pointers 1217 
15 specify negative displacements from FP. Linkage Point- 
ers to Entry Descriptors 1011 and to static data not 
located in Static Data Block 46863 are similarly located 
at negative displacements from SDP in Static Data 
Block 46863, as can be seen from FIG. 468 of U.S. 
20 patent application Ser. No. 266,539. In the following 
discussion, the part of Static Data Block 46863 contain- 
ing linkage pointers is termed Static Linkage Pointers 
46865 to distinguish it from Linkage Pointers 1217 in 
MAS Frame 1201. 

25 Compilers generating SINs for Computer System 
10110 and the present invention do not produce SINs 
which specify addresses at negative displacements from 
SDP and FP as destinations for data. Thus, as long as a 
MAS Frame 1201 or a Static Data Block 46863 exists in 
30 Memory 801, the values of the linkage pointers con- 
tained therein will not change. Because linkage pointers 
are always located at negative offsets from SDP or FP 
and do not change as long as SDP or FP is valid, the 
values of linkage pointers may be encached in Name 
35 Translator 811. The fact that the linkage pointers do not 
change value means that a linkage pointer may be cop- 
ied into a cache without concern for future changes in 
the original, and the fact that linkage pointers are lo- 
cated at negative offsets means that the FU 10120 mi- 
40 crocode which maintains the cache containing the link- 
age pointers can detect NTEs or Immediate Names 209 
specifying linkage pointers and place the values of the 
pointers instead of their locations in the cache. 

Encachement of the values of linkage pointers in 
45 Name Translator 811 is advantageous because it allows 
both Immediate Names 209 specifying negative dis- 
placements from FP or SDP and Names whose NTEs 
specify indirect references using linkage pointers as the 
base location to be resolved without fetching the value 
of the linkage pointer from Memory 801. All that is 
necessary to create a descriptor for the data at the loca- 
tion specified by the linkage pointer's value is to add the 
length and type information for the data to the location 
specified by the encached linkage pointer value. Conse- 
quently, the resolution of such an Immediate Name 209 
or Name takes no longer than the resolution of a Name 
or Immediate Name 209 which specifies a direct refer- 
ence. When a pointer cannot be encached, on the other 
hand, only a descriptor for the pointer’s location may be 
encached, and the Name Resolution operation must first 
fetch the pointer from the location in Memory 801 spec- 
ified by the descriptor and then perform a pointer-to- 
descriptor conversion to obtain the descriptor for the 
data item represented by the Name or Immediate Name 



SIN had to restore calling Procedure 00602’s value for 65 209. 

K. In the present invention, all Procedures 00602 have The increased efficiency offered by the encachement 
syllables containing 16 bits, and it is no longer necessary of linkage pointers is particularly important with regard 
to save, set, or restore K. to linkage pointers to arguments. Since the purpose of a 
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Procedure 1016 is to process the data used as arguments 
to it, there will be frequent references to the arguments 
in Procedure 1016 and consequently many SINs con- 
taining Names specifying indirect references from the 
linkage pointers. Efficient resolution of these Names is 
thus a prerequisite to efficient execution of most Proce- 
dures 1016 in CS 10110 and the present invention. 

While encachement of linkage pointers was possible 
in CS 10110, implementing it was difficult because 
Names were nothing but indexes into NTE 10350, and 
there was therefore neither a way of distinguishing a 
Name whose NTE specified a linkage pointer as a base 
location for the data represented by the Name from any 
other Name nor of determining what Names would 
refer to a given linkage pointer. This fact had two con- 
sequences: 

Separate caches could not be employed for descrip- 
tors corresponding to linkage pointers, since 
Names specifying linkage pointers were not distin- 
guishable from other Names. 

There was no way of determining during the execu- 
tion of a Call SIN what Names in called Procedure 
1016 corresponded to the arguments; consequently, 
there was no way of pre-encaching descriptors 
corresponding to argument pointers, even though 
the descriptors had to be calculated as part of the 
execution of the Call SIN. Encachement could 
only occur on a miss, and at that time, the descrip- 
tor was no longer available. Name Resolve cache 
miss microcode therefore had to fetch the argu- 
ment pointer from Memory 801 and convert it to a 
descriptor in order to encache it. 

As will be seen in the ensuing discussion, the presence 
of Immediate Names 209 in the present invention solves 
both of these problems and greatly simplifies the enc- 
achement of linkage pointer values in the present inven- 
tion. 

1. Linkage Pointer Encachement in the Present In- 
vention 

As explained in the discussion of the Call and Return 
SINs, the position of linkage pointers relative to FP in 
Linkage Pointers 1217 is determined by the order of 
arguments in the Call SIN, and this order is in turn 
determined by the order of arguments in the high-level 
language procedure invocation corresponding to the 
Call SIN. In CS 10110 and the present invention, the 
relationship between the order of linkage pointers rela- 
tive to FP and the order of arguments in the high-level 
language procedure invocation is the same for all invo- 
cations, regardless of the high-level language used. The 
order of arguments used in the high-level language 
procedure invocation of a given Procedure 1016 is de- 
termined by the source text for Procedure 1016 and is 
therefore known to the compiler when it compiles Pro- 
cedure 1016. Given the order of arguments and the 
common formats of all MAS Frames 1201 in the present 
invention, the high-level language compiler can gener- 
ate Immediate Names 209 for references to arguments in 
Procedure 1016’s SINs. For example, as may be seen 
from FIG. 12, the linkage pointer for the first argument 
to a given Procedure 1016 is always at offset —256 from 
FP. Consequently, a reference to the first argument may 
always be expressed by an Immediate Name 209 with 
fields set as follows: 

NTY 203: 00, specifying FP. 

IB 205: 1, specifying an indirect reference. 
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32 DISP 211: —8, which, when multiplied by 32, 
yields —256, the offset of the linkage pointer for 
the first argument. 

An Immediate Name 209 specifying the second argu 
5 ment would have fields set as described above, except 
that 32_DISP 211 would be set to — 12, an Immediate 
Name 209 specifying the third argument would have 
32_DISP 211 set to — 16, and so forth. 

While the locations of linkage pointers in MAS 
10 Frame 201 are a consequence of the manner in which 
Call SINs are executed in the present invention, the 
locations of linkage pointers in Static Data Block 46863 
are directly under the control of the compilers. As ex- 
plained in detail in Section 4.E.d.4 of U.S. patent appli- 
15 cation Ser. No. 266,539, the first time that a Process 
00610 executes a SIN in a given Procedure Object 1001 
which contains a Name specifying the SDP ABP, 
SDPP 30313 in PED 1013 belonging to the SIN’s Pro- 
cedure 1016 is resolved, and in the process of resolving 
20 SDPP 30313, a Static Data Block 46863 is created using 
information in Static Data Prototype 30317 specified by 
SDPP 30313. By convention, all compilers in CS 10110 
and the present invention specify that negative offsets 
from SDP in Static Data Block 46863 contain Static 
25 Linkage Pointers 46865. Since the location of individual 
Static Linkage Pointers 46865 in Static Data Block 
46863 is controlled by the compiler, the compiler can 
generate Immediate Names 209 as described above, but 
specifying SDP, for references to Procedures 1016 and 
30 data specified by Static Linkage Pointers 46865. 

As explained above, Names specifying NTEs which 
in turn specified linkage pointers as base locations could 
not be differentiated from other Names in CS 10110 
without reference to the NTE. In the present invention, 
35 however, Immediate Names 209 specify linkage point- 
ers as base locations, and as described above, Immediate 
Names 209 which do so all contain NTY Fields 203 
specifying SDP or FP, an IB Field 205 which is set to 1, 

and a 32 DISP Field 211 which, when multiplied by 

40 32, specifies an offset which is evenly divisible by 128. 
This is thus only a single Immediate Name 209 which 
may specify a given Linkage pointer in a given execu- 
tion of a Procedure 1016, and more important, if a link- 
age pointer’s position relative to FP or SDP is known, 
45 it is possible to calculate its Immediate Name 209. Fur- 
thermore, an Immediate name 209 specifying a linkage 
pointer may be differentiated not only from Table 
Names 201, but also from other Immediate Names 209. 

The above facts have two important consequences: 
50 First, the fact that Immediate Names 209 specifying 
linkage pointers may be differentiated from other 
Names makes it possible in the present invention to 
employ special cache means for linkage pointers. Sec- 
ond, the fact that there is only a single Immediate Name 
55 209 which may specify a given linkage pointer in a 
given execution of a Procedure 1016 makes it possible 
to preload caches of argument pointers when a Call SIN 
is executed. As represented in FIG. 13, the present 
invention takes advantage of both these facts. FIG. 13 is 
60 a conceptual block diagram of linkage pointer encache- 
ment in the present invention. FIG. 13 has two main 
parts: Name Translator 811 and Memory 801. In Name 
Translator 811 there is shown Cache Means 1301. 
Cache Means 1301 is subdivided into three parts: 

65 General Cache Entries 1303, containing information 
required to resolve all Table Names 201 and those 
Immediate Names 209 which do not specify indi- 
rect reference by means of linkage pointers. 
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Entries for FP-Negative Immediate Names 1305, the new MAS Frame 1201 being constructed by the 

containing argument pointers, i.e., linkage pointers Call microcode what value 32 — DISP Field 211 in Im- 

at negative offsets from FP. mediate Names 209 referring to the argument has. Since 

Entries for SDP-Negative Immediate Names 1307, the values of NTY Field 203 and IB Field 205 are given 

containing linkage pointers at negative offsets from 5 in Immediate Names 209 referring to argument pointers, 
SDP. if the value of 32—DISP Field 211 is known, the form 

Memory 801 contains MAS 00502, with Linkage of Immediate Name 209 in called Procedure 1016 refer- 
Pointers, 1217, as previously described, and Static Data ring to the argument is known. If, as in the present 
Block 46863, with Static Linkage Pointers 46865. As embodiment of the present invention, Cache Means 
indicated by the brackets and arrows, descriptors de- 10 1301 is an associative cache, Call microcode may enc- 
rived from argument pointers in Linkage Pointers 1217 ache the descriptor corresponding to the argument 
are encached in Entries for FP-Negative Immediate pointer by constructing Immediate Name 209 corre- 
Names 1305 and descriptors derived from Static Link- sponding to the argument pointer, using Immediate 
age Pointers 46865 are encached in Entries for SDP- Name 209 to locate an entry in Cache Means 1301, and 
Negative Immediate Names 1307. 15 placing the descriptor in the entry. If entries for FP- 

In the present embodiment of the present invention, Negative Immediate Names 1305 is a cache addressable 

cache Means 1301 corresponds to NC 10226. NC 10226 by the value of 32_DISP Field 211, on the other hand, 

is an associative cache, and thus, the subdivision into the descriptor may be placed directly at the proper 

three parts is a simple consequence of the fact that Im- location in Entries for FP-negative Immediate Names 
mediate Names 209 specifying linkage pointers have the 20 1305 without constructing Immediate Name 209. In 
special forms described above. In other embodiments, either case, preloading reduces the number of misses in 
Cache Means 1301 may in fact comprise two or more Cache Means 1301 during the execution of a Procedure 
caches: General Cache Entries 1303 may be an associa- 1016. Furthermore, since the descriptors corresponding 
tive cache responsive to Table Names 201 and Immedi- to the argument pointers are available during the execu- 
ate Names 209 which do not specify indirect references 25 tion of the Call SINs, preloading may be done without 
involving linkage pointers, while Entries for FP-Nega- fetching the value of the argument pointer from Mem- 

tive Immediate Names 1305 and Entries for SDP-Nega- ory 801. Both the reduction in the number of misses in 

tive Immediate Names 1307 may be caches addressable Cache Means 1301 and the increased efficiency of load- 

by 32 DISP Field 211 for Immediate Names 209 ing increase the speed with which the present invention 

which do specify indirect references involving linkage 30 executes Procedures 1016. 

pointers. The latter type of cache is possible in the pres- 2. Implementation of Linkage Pointer Encachement 
ent invention for two reasons: first, the values of NTY in the Present Embodiment 

Field 203 and IB Field 205 in such Immediate Names In the present embodiment, Cache Means 1301 is 
209 immediately distinguish them from other Names implemented by means of NC 10226. A single descnp- 

and distinguish such Immediate Names 209 specifying 35 tor, that corresponding to the argument pointer for the 

FP from such Immediate Names 209 specifying SDP. It first argument of the Call SIN, is preloaded by Call 

is thus possible to construct special caches which re- microcode. Otherwise, NC 10226 is loaded as in CS 
spond only to such Immediate Names or indeed only to 10110 by Name Resolve cache miss microcode. In the 
such Immediate Names 209 specifying SDP or those present embodiment, Name Resolve cache miss micro- 
specifying FP and to present a Name simultaneously to 40 code examines the Name which caused the miss. If the 
such specialized caches and to a general associative Name is an Immediate Name 209 specifying a linkage 

cache. Second, 32_DISP Field 21 in such immediate pointer, Name Resolve cache miss microcode obtains 

Names 209 is in fact the FP or SDP-relative address of the value of the linkage pointer from Memory 801, 

the linkage pointer. If the linkage pointers are encached converts the pointer to the AON and Offset portions of 

in caches corresponding to Entries for FP-Negative 45 a descriptor, and adds the necessary type and length 

Immediate names 1305 or Entries for SDP-Negative information. Cache miss microcode then encaches the 

Immediate Names 1307 an order corresponding to their resulting descriptor for the argument in NC 10226. The 

orders in Linkage Pointers 1217 or Static Linkage entry RES_C_Miss in RESOLVER _TRAPS of 

Pointers 46865 respectively, then 32_DISP Field 211 Appendix A illustrates encachement of linkage pointers 
may serve directly as the address of the encached link- 50 in the present invention, and the entry NCALL_END 
age pointer in Cache Means 1301. of NEIGHBORHOOD _CALL illustrates preloading. 

In the present invention, Entries for FP-Negative As mentioned above, other embodiments of the present 
Immediate Names 1305 may be preloaded by Call Mi- invention may preload additional argument pointers 

crocode as part of the execution of a Call SIN. As and may employ special caches for linkage pointers, 

pointed out in the discussion of the Call SINs, when a 55 The invention may be embodied in yet other specific 
Call SIN is executed, Call microcode resolves each forms without departing from the spirit or essential 

Name specifying an argument in the Call SIN, converts characteristics thereof. Thus, the present embodiments 

the descriptor to a pointer, and places the pointer on are to be considered in all respects as illustrative and not 

Linkage Pointers 1217. The descriptor corresponding restrictive, the scope of the invention being indicated by 

to the pointer is of course the value which should be 60 the appended claims rather than the foregoing descrip- 

encached in Entries for FP Negative Immediate Names tion, and all changes which come within the meaning 

1305. In CS 10110, there was no way of determining and range of equivalency of the claims are therefore 

during a Call what Name in called Procedure 1016 intended to be embraced therein, 

corresponded to the argument, and thus, there was no APPENDIX A 

way for Call microcode in CS 10110 to encache the 65 

descriptor in NC 10226. In the present invention, on the This appendix contains the source texts for the FU 
other hand, Call microcode can determine from an 10120 microcode used to implement the present mven- 

argument pointer’s position in Linkage Pointers 1217 in tion on the hardware of CS 10110. For a description of 
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how to read FU 10120 microcode source tests, see Sec- 
tion 2.F.d of U.S. patent application Ser. No. 266,539. A 
detailed description of the FU 10120 microword is con- 
tained in Appendix A of U.S. Pat. Ser. No. 266,539. 
Taking Section 2.F.d. together with Appendix A, one 5 
skilled in the art may read the source texts in this appen- 
dix. The source texts are arranged in the order in which 
the inventions they implement are discussed in the De- 
scription of the Preferred Embodiment: 

Microcode for Section A: 

PIR _TO _DESC and DESC_TO_PTR: These 
implement descriptor- to-pointer and pointer-to- 
descriptor conversion using the pointer formats of 
the present invention. 

Microcode for Section B: 

RESOLVER _TRAPS and RESOLVER imple- 
ment Name resolution and Name Cache 10226 
maintenance in the present invention. The micro- 
code resolves and evaluates Table Names 201 and 
Immediate Names 209, and performs these opera- 20 
tions for Table Names 201 using NTEs 307. 
RESOLVER TRAPS is microcode invoked by 
Name Cache 10226 misses and jams, as described in 
U.S. Pat. Ser. No. 266,539 3.B.c.3.d.d. and e.e., and 
RESOLVER is microcode used by RESOLVER- 25 
TRAPS. 

Microcode for Section C: 

EMULATE_2400 is microcode which forces FU 
10120 to read a 16-bit SOP by reading the first 8 
bits of the SOP, forcing K to 8, reading the second 
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8 bits of the SOP, and then resetting K to 16. 
Microcode for Section D: 

CSL.DISP 2 and ACCUMULATION_ EN- 

TRIES are source texts for the microcode imple- 
menting the accumulator SOPs. CSL.DISP 2 

specifies the dispatch table loaded into FDISP 
24218 and ACCUMULATION ENTRIES spec- 

ify the actual operations of the accumulator SOPs. 
The discussion of SPL S-language microcode in 
10 Appendix B of U.S. Pat. Ser. No. 266,539 describes 
how CSL.DISP _ 2 and ACCUMULATIO- 

N ENTRIES may be read together. 

Microcode for Section E 

The microcode for Section E is the microcode which 
15 carries out the GCALL, NCALL, NCALLN, and 
RTN SINs. It consists of the following: CAL- 
L_ Entries, containing the entries RTN, NCALL, 
and GCALL for those SINs, and SET UP N- 
CALL for NCALLN; NEIGHBORHOOD- 
CALL, containing the microcode for the 
NCALL SIN, LEVELS _S_ RETURN, contain- 
ing the microcode for the RTN SIN, and level- 
S CALL, COMMON _CALL, _ CALL- 

STATE, and GENERATE MACRO S- 

TATE, containing the microcode for the GCALL 
SIN. 

Microcode for Section F 

The microcode implementing linkage pointer enc- 
achement is contained in RESOLVER TRAPS and in 
30 NCALL END of of NEIGHBORHOOD_CALL. 
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r? t AL) 10 ACCUMULATOR USING OF f _ 4 LU WITH PREVICUS(7) 
C0N_LENliTH(32) , 

OFF ALU OUT = 5 I A SE U_LENG f H PLUS PRE V IOUS C 77 , 

LUAU_a09f UTU.AOOP ) wTTH AQNtPREV TOUS ( 7 ) ) , 

I.UM;_GFF iU T U_Anu° ) i.'TTH OFFSET; 

rFF_ALU_'HjT = 7t c 0 UP P lP_nFF SET, 

I ua”_L'FF f pPEViniiR ( 7) 1 a 1 T 11 OFFSET, 

I lj * u”aO,,| ( pof V l Ol S C 7 ) 1 1 T n 0 ! 

OFF_AL"_-l u T = ACT Ox L0l;_4, 7 * U1D 0..15 */ 

S L' 1 'HO E 1 OF F _aL U_U A T A ) TO .1 2 o JSL'S ( 0 AT A _TR AP 3 , 

L u * 0_L F >4 l CURF F N T 1 7 1 1 ‘|Th u^F, 

Li/AoIuFF cru D 6F;..Ti7) 1 1 t h so., ( con_0 ) , 

C45 t -U*j ACC.n t Tl ( t 3 '-’ASF i“'iu OUTATEU); 

/* uO - "10 Pointer */ 

0FF_a L U_OuT = 7E°u u° ALC_"1, 

IF (JF F_LO_f* TnEh G0|0 uin_pp?; 

/« 60 - 4 ssocietFO Ulu pointer */ 

r)(.p_A|_il_ n (jT - ON c L £ F | _oH I F | P 0 ( 7 1 XOR ACC_HI, 

IF ~FF_t 0 _n THFn. u OTn AsSurjIIO; 

/ * b 1 - Infre n n i e r t Pointer * / 

1 L‘A ii_AO:'« (PPt u 1 PL’S 1 7 ) 1 •.-! T r , ftO.-j f U To_AOu B ) , 

OFF_*L"_OUT = Or. F V,)F AtCJU. 

1 4 i>FF_f7_0 ThF 1 1 GOTO I ■•.T*#_n 0 JECl f 

/, ,<1 - Sjtocieten Intrj ■ J 6jo c t' p oin f er */ 

npc _AL"_OU T = 1 l T 1 4 | 4 (■ |.j 1 Y 1 . 1 P Acr_Hl , 

l u a u ( a l r. u u t. a T j D ) . i r I w 0 F c S F r ; 
n F F_ALU_ r ij r - ■" lO ok 

IF "FF_t n _o ThP «r>ro AS < 5 or_T.-iTKA_OoJECT f 

/* back -ip UTO.AOUP to address the first bit in the pointer 
so t^e siqna' will pass out the correct data. */ 

OFF ALU_ n UT = BIASED.LFNOIH C 0N_LE NG TH ( 3? ) REV_MTNUS UTD_ADDR, 




4,428,045 



54 



53 



492 0 

49 3 0 

494 0 

495 0 

496 U 
4 9? u 

4 0 H 0 

499 U 

500 0 
54 1 U 
502 0 
54 4 t) 
5 n 4 u 

545 0 

5 0 o 0 

50 t 0 

546 0 

544 0 

510 0 

511 UC 

512 0 

513 0 

514 0 

515 0 

516 0 

517 0 
516 0 
514 0 
520 u 
5 2 1 0 
522 0 
52s 0 
5?4 0 

525 0 

526 0 

52 7 0 
526 0 
529 0 
S3u 0 
5 x 1 0 

532 0 

533 u 
5*4 o 
536 o 
33o 0 

53 7 U 
5 3b U 

534 o 

54 0 0 
54 1 (i 
542 0 
54 3 u 
54 4 0 

545 0 

546 0 
54 7 o 

54 6 0 
544 (i 

550 0 

551 u 

552 0 

55 s 0 

554 0 

555 u 

556 0 

557 0 

556 Cl 
554 0 
56u 0 
561 0 

562 0 

563 0 

564 0 



UlAD.OFF (CURRENT f /) ) WITH OFFSET, 

I UAU_AO|, (CDkPfcMT f 71 ) n I | H A l)M ( 1 1 1 D_A00R ) , 

L UMU_C ULL SUPPORT *.5AVE_ACC_1’'10_1 »APS ? 

5 jr-\AL_lMn_P0PtP0T;4TtR_FA'lLT,CUPREMT( 7) , RETURNABLE ) i 

R£TuRN_FRUN_S lG h AL : 

I.UAD_AON(uTu_AnUP) ^ITH 6, 

L u(-!G_L»Ll 5|jPpn|yT *Otl5 rORF_ACr_4N0_THAPS ; 

OF F _» L I '_OU T = ONE L£F!_5HiFIEl>(7) R£V_MINUS SP, 
LUAU_AOw(CIJPRE m I ( 7 1 J e T TH Au f 'C?P), 
lueti.OFF CC'iWRE M T( 71 ) ,v I T*-» n F F SF 1 , 

LOA'G_LALl. p T R_TL'_UF SC ; /* retry alter signal */ 

COPY (PREVIOUS (7) ,CUfi«EN [ (71 ) , 

LU A y ( ACU IMULAT OP 1 WITH OFFSET; 

/* Get o’d SP offset fro" sianal packet where it was 
cur by the return path of i n v o k e_s i gn a 1 1 e r . */ 

Rt'-u 10 r u gpe,..T_7 'JSl.yG OFF _Ai.ii with SP CQN_LENGTH(3?) , 
n F F _A lU_0u T = L 1 T 1M Sin!lAt_PK I .6K_SP) R£V_MINUS SP J 

/* Pop the signal packet off the stack. */ 

HF F _AL 0_°U T :H]»,jFo_LF4f.[H C 0N_L ENG T H ( 0 ) OR CURRE M F(7), 
L U A y_u F F f SP j i-v TIM OFFSET, 
f>ISAPLE_AUA'_WR 1)5, 

Rt TijRi, ; 

1 4 tr a_Om.j t C I : 

0PF_al'. | _ 0UT = 7ER|J uR PRFi/Tul'Sf 7), 

Load ( ACCU’^UI. A Tl)R 1 ri T T h 6 FF 3 FI, 

L u a u_aor ( u t n_ H no 0 ) wTlH 0, 

RETijPi.: 



IJ 1 n_P 1 o : 

PtAy 10 ALCU^Ol ATyR USTijG OFE_AlM, L0N_LENGTH ( 32 ) , 
nPF_A L M_nur = BIASFO.IENGTH PLUS UU)_A00R; 

R t«0 10 CU c wEi>i 1 _6 'JSTilC- 0FF_A|_" C0N_l Et'GTH ( 32 ) , 
OrF_A L M_OuT : L I T l 6 ( 64 1 PLUS UlO_AOOP, 

I- UA o_AOA, f u T i>_A0L’R ) ivl FH 0; 

S£ T_ v t;N_'-'ASn , 

OrF_A u !!_n U T ; c L r Ow C 1 r ’> e "■ T ( 7 1 , 

L JAO.LFN ( ruFhF IT C 7 ) ) UTn U R F, 

L U 4 1 ) r A r C 1 ' 4"i_ A 10 |<) ■* I T r- 1 (CURRENT ( 1 ) ) ) , 

I LiA0_0FF FC M l-PE M T ( / 1 ) .TIM IPO ( I.E*' (C uPRFot T ( 7 )1 ) , 

I U W G_L A LI. A 0 M _ HI O »J 1 1 r _ T L' _ » 0 ■„ : 

CLR_’ 4 0N_*!aSk , 

L 0 A j _ A 0 h (PREVIOUS! 7 ) ) WITH 4 ON (CURRENT (7) ) , 

(F ao n _£--)_q Then GOTO ijio_7ERu? 

LUAO.AOn (CURREHTl?)) with 0, 

0FF_AL'I_0UT = 7ERO OR PRE V T uUS ( 7 ) , 

LUAQ (ACCUMULATOR) hlFH OFFSET, 

° E T U R i, ; 



t.'in.ZERG : 

o F F _4 L 1 1 _ 0 u T = OwE R£V_«INIJS C QN_fl 0 0 0 0 0 0 0 , 
L0AO_uFF (PRF V I ullS (71) *TFH OFFSET, 

L U A 0 lACCU M uL4TijP) w I I h OFPSFT, 

LUAO.AOu (PrtFVTUUS ( 7 ) ) e T 1 H 0, 

0 1 T 1 J R N J 



TPAGE 

A S Sur_T NTR A _00 J tC I : /* convert AON to UIO */ 

SET _*hqN_M a S K , 

UlAOF ACC'IMULA 10R1 WITH AO.M ( U 1 0_A00R ) , 

LUNG_C ’LL auNJ'IP* A0N_TU_UTD ? 




4,428,045 



56 



55 



56 5 (t 
560 0 

567 0 
566 0 

569 u 

570 0 

571 0 

572 0 

573 0 

574 0 

575 0 

576 0 

57 7 0 
576 0 

579 0 

580 0 

581 0 

582 o 
5«3 0 
564 0 
585 o 
5 fl t> U 

58 7 o 

568 0 

569 0 

590 0 

591 u 
5°2 u 

593 0 

594 0 

595 0 

596 0 

597 0 

598 0 

599 0 

600 0 
60 1 0 
602 0 
603 0C 

feO 4 0 

605 0 

606 0 
60 7 0 
6O0 0 

609 0 

610 0 
611 0 
6 t 2 0 

613 0 

614 0 

615 0 

616 0 



CL° J u, ljM_"A6« , 

npOuCnuT = ZERU Q9 rU9HF,4T(7), 

I Oft!J_OFMuTD_0. . 15) V 1 T n OFFSET, 
LjAij_mPu(UFl/_0. . 1 5) 'VI Th 0: 

9FF_ALU_ni.IT = Zt9u U9 r L i°REN T ( 8 ) , 
LUAD.OFF (!'10_1 6. .4 i ) '<11 Th OFFSET, 
LuA(J_AON (Uin_l6. .47) Sf' 1 Th 0, 
L.uMG_G9|'l A5Sor_4tAHCH: 



ASSuCJJIP: /« fetch the UTO */ 

READ TO _U I 0_0 ..15 U.SiMb OFF.AIU C0N_LENr, TH ( 1 6 ) F 1 1 1 ( 9 I RHT , ZERO ) 
OFF _* L"_OU f = I. 1 T 1 6 ( 16) PLUS U T D_ADQR J 

READ 10 _u ( G_ 1 6 . .47 US I mG OFF_ALU, CCIN_LENGTH ( 32 ) , 

9FF_ALU_0UT = LIT16C32) PLUS UID.ADOR; 

READ rn _UtO_48 .. 79 USTUG 0 FF_alU CUN_l ENGTH C 3? ) , 

OF F _A L 1 l_0'J T = L1T16C64) P L"S UID_APUP; 



ASSur_SEAKf h: 

/» get 3 laress o f assoc aor*r table */ 

OFF_AL"_OUT = L 1 T 16 ( S 1 ACK_me AUFR .SOLP) 09 CllN_ 0 , 

• 0 A 0_U F F iruPR p UT(7) ) WITH ijFFSET; 

I OAQ.AOlj (CURhF.-.T 1 7 ) 1 W 1 T H AON (SIP), 

LuMl_CAl(. ° TR_Tu_')E SC ; /* this better n 0 t be an A A T Dointet */ 
LU f 'Ui_C ALL AAT_l U0K'JP»AA T .LOOKUP) 

WITh CURP£ m 1(7), 

IF LF N_i'*F_0 ‘ T hFnt GOTO FOIJhO.FnTRY ; 

/* Back up UlO_AOij9 to point to beoinnina of pointer so sianal 
wi'l pass out correct Parameter. */ 

oFF_ALH_ 0 gr = B I a bFl)_LF,\iO r *-* CgM_L ENGTH ( 3 ? ) HFY_M t NUS UTD.ADDR, 

Lu A [) OFMCUHRtM ( 7) )~>T1H OFFSET, 

!. JAu”flO,j(CUK p E‘‘ 1 < 't ) ) .<T1H AO‘i(U10_ADC'R), 

LUMgIc all SUPPORT *SAVE_ArL_AMO_TRA p S 7 

S I 0 H A L _.’iO_PGP ( *Hj_A c O n C T A T E n _AL ir, 9 FSS,CLIF 9 FUT ( 7 ) jRSTUHt'ARLE) J 

L 0 A.j_AOh f CUVPt 1 ( 7 ) ) . T T u 0, 

!. oUb_uO |9 PETU 9 i._F“ 0 P_ c ir-,iAL: 

FOUNO.FNTHY : 

CuPr (PREVIOUS! 7) , CURRENT ( 7 ) ) > 

LOMG_GOTO 0 (R_T0_DFSC; 



f p U T FILE: 7 ? I . 1 _F T L F 1 A 



■(JECI FILE: PTH_TO_DESC.OP 



INE N : Su'JRCE 



4 3 7 U : EM p » PTh_TD_0£SC : 

438 0 : PEao TO ACCUPULA fOR uSI M G DESfRIPTuR PREVIUUS ( 7 ) , 

M 0 : mem 1 .uri 1 5b_ctrl 0 stc.f ’■a”? 3 , resource 7 , 

439 0 : L0Af)_AC'f ( CURRENT ( 7 ) ) HIT* 0 , CON_LENGTP ( 32 ) 

H 0 : dest_frame d , r_dest 7 , r_w 1 a_i n 0 , ten_ctrl 6 

439 0 : ; 

441 0 : eutpt kE ao_s f ar rE n : 

442 0 : 0FF_ALU_UU1 = ACC X OR COM M UU ( Tie? , 3 ) , 

M 0 : alu_in 5 alu_oo 4 sre.f rare 2 , r_source 3 , com_ext SICS) , 

443 0 : LOAD _0 F F f C URRFgT ( .? ) ) WITH OFFSET , 

M 0 : aest.frame 0 , r_Hest 2 , r_w 1 o_in 3 , 

444 0 : C A SF On ACC_8 y 1 E ( 0 1 MASK ai8 OS' RUTATE 1 1 ) 

16 0 ! nac 3 sree 4 "ask Si 8 0 -0 sc 6 

444 0 
44/ V 



0 T 5 Atjl E_A0N_wR i , 




57 
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58 



A 0 
446 0 

M 

4^9 
M 

4S0 

4 



45 0 0 
45 i 0 



>.+ 


0 


S 71 • rn 1 ?i ^ 


1 4 o.ctrl 


1 s rc_F rane 


3 , r 


.source 7 


454 


U 


: co,_LF|.,oru 


f ) , 










t*l 


U 


: 1 *fi_ct r 1 6 


t 










455 


0 


: ll F F _AL U_UU 1 


- a r a5F p_i. 


tNiTh PLUS P H F V T u u s 


l 7 ) 


/ 


TV- 


u 


: a ' u _ i 0 t 


a 1 u_oo 3 


snc.frjre 3 , r 


_source 7 


9 


45o 


0 


: loao_4u'i ( 


Cu»RF-r ( 1 


) ) /II Th AO | 1 


PPE VI0US 


C 7 ) ) , 


M 


0 


: tiest_*rane 


F , r_dest 


l , r_K 1 a_i 0 


£ 


9 s rc 


_f rane 


4 


u 


: 3 , r.sourct 7 , 










457 


0 


loao_pff ( 


ro°rFi,. t ( 1 


1 ) UlTf, j F F 5 c. T 






M 


0 




n , r_oesc 


1 , r _w 1 0 i n 


3 






457 


0 


t 












459 


u 


(jF F _AI U_U" f 


: A FRO Ok 


CHRPt^l ( Z ) # 








'A 


0 


a 1 u_ 1 0 P 


» ran ) Z alu_op 5 Src_frame 0 


, r.source £ 


460 


0 


0 0 A 0_f)F F ( 


PkF y T JUS ( 


7 ) ) aHH 0FF3F 1 , 






M 


0 


desf_(rane 


3 , r_de st 


7 > r_w i o_in 


3 


9 




461 


0 


LOAO_AU m f 


ORFvTuUS l 


7 ) ) WITH 0 








M 


0 


tltSt.irK®* 


3 , r_4est 


7 . r_v« 1 a.in 


0 






461 


u 


i 












463 


U 


uff_alu_uh r 


= 4 C C 0 P C 


0*5-1 or. ( ,a, , 0 


) , 






M 


0 


a 1 u_i n P 


a 1 u_co 5 


src.lra*e £ 1 r 


.source P 


9 com.ext 


464 


U 


: SOUP C F f 0FF_A L il_O.i T A 


) fO IpOJAuS ( 


OATA_ 


TPAP 


) , 


.V| 


0 


j ra_c t r 1 7 


ae v_c*"d 


£p 








465 


0 


LOaOJ t N ( 


Cuprfnt < 7 


) ) 7 1 T n UFF , 








M 


0 


dest_fratr«» 


0 , r_4est 


7 1 r_* 1 1 _i n 


3 


r ah_ 


Ctrl 1 , 


46d 


u 


LO„0_nF5 ( 


CuPPEUT ( 7 


) ) I T H rt ON ( 


lUmvon C 


F)b5l , 0 ) 


‘•1 


0 


uest_ f rarr'o 


n 9 t 


7 / r_ w 1 0 0 


£ 


1 S rc 


_fra»e 



46 7 0 
'4 0 

46 7 0 
47(j 0 

M 0 

47 1 u 
'•1 0 



rand P , 

UFF_ALU_CH.IT = ACC UP C0 M M0* ( «3o) , 0 ) , 

a'u_in 2 a'u_oo 5 sre_frane £ # r_source 0 
L 0 A D _o F F ( PR c v t UU3 ( 7 ) ) rtllH OFFSET , 
(Jest_frsm» 7 , r_dest 7 , r_w 1 o_i n 3 , 
UPTURN 
nsc £ 



REAP T U aCCUmUlAFOk US1MG uFP.ALU « I TH PREVIOUS ( 7 ) 



t con.e»t FiBFi 



r _ s o u r c A 0 , co"'.»iit iioil 
CASF Oil ACC_»VIE f i~l MASK .iPja »0TATt ( 1 ) 
nac A srcf 5 >naSk ^61* sc 6 

9 

0FF_ALJ_U"1 = ^F R Tl OR ACC_H I , 

alu.jn ? , p a nd z *t|u_op 5 dev_cmd I , 
i c nFP_P,,_ u THtN GOTO uTD_PTR 

test 6 , polarity n n a c a , l,ra UIP_P1R 



471 0 

474 0 
M 0 

47a o 

M 0 

475 0 

47 a o 

4 0 

M 0 
479 0 
.4 0 
4 A 0 (J 
M 0 
4 P 0 0 
483 0 
4 0 
4P4 0 
M 0 
4 A 4 U 
4A6 U 
4 0 
4« 7 0 
M 0 
4 P 7 0 
4° 1 (J 
491 0 

M 0 
49 C 0 

!'1 0 
495 0 



UFF_AI.U_uH| s UMt LFF T_RtiT F TEO f 7 ) XjR ACC.HI , 
a'u_in ? , raod 3 Jf / a I u.op 4 dev_cnd 1 , 

if off_fu_o f h e n f.jtu « c soc_uro 

test 6 , polaritv 0 o a c 4 , lira ASS 0 C_UID 

9 

L r> A 0 _AuM ( PRF V T (J* 1 3 ( 7)1 WITH A QN ( CUPRFNT ( 1 ) ) , 

d»st_*rame 3 , r_R est 7 , r _ w j *_j n g , src.fra»e 
U t r_sourc* I t 
UFF_ALU_UDT = <JN£ FOR ACC.HT , 

alu_ir ? , rano 5 alu.op 4 dev_cnd 1 , 

IF OF F_Fu_u THEM GOTO 1 4 T R 4 _OP JE C T~ 

test b , polarity 0 n a c 4 , l,to TNTRA_OdJECT 

9 

UFF_AI. U_J"T s Lllto ( dP|F) ) FOP ACC_HI , 

alu_in 3 » ' 0 # 1 i t 1 6 I ui 3 ' u_ 0 O 4 dev end 1 , 

LOAD f ACCUMULATOR ) WITH OFFStT 

<S_ W i r 0_ 1 n J 

9 

UFF_ALU_UH| = ACC JR Cum.'. Oh ( , u p ,i , 0 ) , 

a>u_in A jlu.or 5 src_fr a n«» 2 , r_source 0 , con ext Tifca 
JF OFF _F'J_o [H t N CuT 0 A 3 SOC_lNr°A_U«J 
test o , polarity 0 n-jc « , Ijf 6 4 SS 0 P_INTRA_ 0 BJ 

9 

UFF_Al.u_uH I = a r ASt r '_LcNoTrt COli LFFiGIH ( 3 z ) RPV MINUS 

cukPfc/n t : ) , 

a'u_in ! I'n.c'rl 6 a'u_oo I src_f rjee 0 , r source 1 
LOAO_OFF f CURRENT ( 7)1 WITH uFFSET , 
dest.Frane n , r_ 4 est 7 , r_w 1 o_'n 3 , 

LOA[>_AuN ( CUPrEiiT ( 71 ) WITH 40.4 ( CURRENT ( 1 ) 1 , 




4 , 428,045 



59 



■•I o 

M 0 

4 a 4 o 
m u 

49-4 0 

49 0 0 
49o 0 
M 0 
*1 0 
M 4 
49b 4 
4°b 0 
■I U 

i v t 0 
M 0 

49b u 
M 0 
49b 0 
4 Q b 0 



60 

2 i src_frane 



49b 0 
M 0 
M 0 
;-i o 



4°o 

49b 

49b 

4°9 



0 
0 
0 
0 
14 0 

504 0 
<A 4 

590 0 
5 02 4 
M 0 
•'•I 4 

505 0 
14 0 
A 0 

504 4 
1*1 0 

505 0 

M 4 



505 

507 

507 

M 

M 

M 

507 

507 



0 
4 
0 
0 
0 
0 
0 
4 

M 0 
M 0 
50 7 0 
M 4 
50b 4 

-t 0 
50« 0 
5 1 2 0 
5 1 2 0 
M 0 
H 0 
515 0 
m 0 

i-i 0 
515 0 
51b 0 
4 0 
517 4 
1-1 0 



dest_trame 0 , p_4?st 7 , r_w l e _ i n 
0 , r.sourc* 1 , 

l_oiMr, tall b'ipPo9f * su-f _acC_A,,r>_TK 
nic 7 , lit 14 SUPPORT * S A VE _AC C_A ND_T 9 

I’luTvTbldLE , uFh_iLi7_Jl.il = into 1 **\?Z* 1 OK COMMON 
( 4 , c 1 , lOAO.ofF ( CJMMOh (4,5)1 

ranri 15 , » I >j_i n 5 , I 4 , lit lb .i(Al?2P alu.op 

5 src ( r aca 2 , p.sourta c , c nm_e x t 4 , H est_f pa^e 

Z , r.iiasi 5 , cop.axt 0 , r_w 1 o.m 

t.HH "fFoFT , L o a 0 _L t M < r t u * 5 ) ) «ITH 

LTTFkAl l L O „_L F ...-r, | w r A 1 ) , l jA|:_A n N 1 COi-iMUfJ ( 0 , 

5 , (jp s t _ * r »it- •» 2 , p.'iest 5 , CP*_e*t 4 / r_K 1 

l_in 1 , |an_c f rl 0 , nest_tr»me 2 , r.Hest 

5 , com.ext 4 , r_* 1 »_in 

I I H 0 

n 

; INDIVISIBLE , OFF.AlU.OUT = bT ASED.LENGTH con.length 
14)0° CuPREu I ( 7 1 LjAD.UFF l COMMON <0,4)1 



5 ) 1 



M 


0 


; r and 15 


t 


^ 1 u_i n 1 




1 en_c t r 1 


4 alu.op 5 


M 


4 


s rc_t pa*e 


0 , 


r.sou r c * 


7 


dest_f rariie 2 , r_dest 4 


M 


0 


, com_e«t 


0 , 


r_w 1 o_ 


,i n 




0,4)) WITH 


49b 


0 


: wTTH OFFSET , 


^DuO — AuM 


( 


CuMlOlx ( 



5 , dast_(pa»e ? , p_Hest 4 , c(i"_ext 0 , 
a_in b , spc.f p a m e 0 , r.soufcf 7 nac 
TNVUKt.STlxMALLF * 

IN 4 OKF_SlOi-jAC.Lt 



r_w 1 
7 , I i t 1 4 



RFTUHN_FRnM_SlG : 

LOAO_AUN ( CURRFjjT (11) WITH 0 , 

aest_frame 0 , r_clest 1 , r_w 1 a_i n 0 , i 

LONG.CALL SUPPOP r * MF$Ti)Rt_ACC_ANU 

nac 7 , 1 i t 1 4 SUPPORT * P E 5 I OhF _A C C _A NO 

ij F F _AL U_liU 1 = jN t cE F T_Sh I FTEO < 7 ) 3EV_«1NUS COMMON (2,5) 

a'u.m ? , p a po 5 st 7 a I u_op 1 SPC.freme 2 

, r.spurcf 5 , ccT_ext ? , 

LOAn_AGN ( roPKF.jt ( 7 ) 1 PjTh AO,\j ( COMMON C ? , 5 ) ) , 

dPSt_frarr.p 0 , p.^est 7 , r_* 1 a_in 2 , src_trapf 

Z , r.snurce s , cam.ext ? , 

Ln A n _PF c ( CU°FF NT ( 7 ) ) •■' i 1Th OFFSET , 

Oest_(ra*p 0 , r.Hest 7 , r_« 1 o_in 5 , 

L 0|jG _C ALL PT K_ | O^Pfc S C 

nac 7 , lit Ip PrP_Tu_OFSC 

OFF _A1. 0_Jli I = /FRO Ok CURRENT ( 7 ) , L0AP_A0M ( 

PREVIOUS C 7 ) ) WITH AON ( CURPEM I ( 7 ) ) 

a I u_i n 2 , p an 0 2 a I u_op 5 sre_trsnie 0 , r.souree 

7 , Hest.fraa'e 5 , r _ J est 7 , r _w I a_in 2 , 

SPC_t f a"e 0 , r.souPca 7 

, LOa 0_LEM ( PREVIOUS l 7 ) ) rtllH LEN ( CURRENT 
17)7, LO«0_0FF ( PfiFVIUUS ( 7 ) ) nlfH 

, oast _t ranp 5 , r_Hest 7 , r_p 1 T_'o 2 , src„fpa ,n e_ 

4 , r_s ciu pc P 7 , oPSt_tramp 5 , r_Hpst 7 , r_ w 1 o_in 

uff.slt , 

5 , 

LOaO ( ACCUMULATOR ) '• 1 T 1 1 ‘j F F 0 E T 

a_w 1 , o.i" j 

REAP TO CUK R t 'I T _ / L'Sl M l, oFF_AIU nITH COMMON 1 2 , 

5 J CPN_LE iC-lK * V ) , 

mem 1 id 15 qi'.ctpl 1 src_fna""e 2 , ".source 

5 , ccm.ext Z I e"_ct p I b , 

UFF.ALU.j"! - Ll Ho ( 1°2 ) REv.wTNUS C0 MM UN < ? , 5 ) 

alu.in 5 ,'o, 1 t *■ 1 A 192 alu.np 1 src.lrame 

2 » r.spu p ce c , po*_pxi 2 

UFF ALU UUT = ttTASEO LENOTh COaLLENGTH ( 0 ) OR CURRENT ( M 
a”u_i n 1 len_ctrl~0 alu.oo S src.frame 0 , r.source 7 
LOAO.npF f COMMON 1 2 , 5 ) ) *IH OFFSET , 

destltrame 2 , p.Hest 5 , co".e*t 2 , r_w 1 o_in J , 
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61 

5 1 a 0 : l>IS»£iLE_An-..j_*Ri , 

MU : f5nri S , 

“519 0 : rFPJKN 

4 0 : n a c 2 

519 0 : ; 

5? l 0 : l n T 9 a _ u FI J f c T : 

5?2 0 : 0 F F _fl L U_0< ' f = 2FnO Oh RRtVIOUS (71, 

■"i 0 : alu_jn ? , p a no c a I u_od 5 srp.f raue 5 , r.source 7 , 

5? 3 0 : LOAD ( ACCUMULATOR 1 WITH OFFSET , 

M 0 : a_* 1 , o_in 5 , 

5 ?4 0 : LnA0_AQM ( CURRENT (1)1 KITH U , 

M 0 : oes t _f r ame 0 , r_rtest 1 , r_,e 1 a_in 0 , 

525 0 : RETURN 

M 0 : nac 2 

525 0 : ; 

5?8 0 : Ulu.PTR ; 

5?9 0 : READ TO ACCUMULATOR USING OFF_ALo , CON.LENGTH ( ?2 ) , 

A 0 : mem 1 md 1 db.ctrl 1 , ler»_cfrt h , 

53o 0 : OFF _ALU_'JI • T s a T A Ft n _L E'-'G Th PLUS r u R R E N T ( 1 1 

M 0 : a’u.in 1 a 1 u_oc 5 src.f fa'e 0 , r.source 1 

550 0 : ; 

5 52 9 : RF AD To CMK9F.MI.6 OS I ''b UFF_ALU CDn.lFhGTH ( 52 ) , 

•-I 0 : mem 1 md I A dH_Ctr| 1 len_ctrl a , 

555 0 : OFF.ALU.UUI s Lfflo l ou 1 PlUS cUi<P t M| ( 1 ) , 

M 0 : a lu.i n 5 , 1 0 , 1 i t 1 a b'A al u.oo 5 src.f raae 0 , r.source 1 

554 0 : LDAD_AI|M ( CURRENT ( | ) ) KITh U 

M 0 : oest.l name 0 , r.nest 1 , r _.i 1 a.in 0 

554 0 : ; 

55b 0 : SF | _;<iOk_ IAjK , 
id 0 : dev.cmd /? , 

5 5 7 0 : uFF_ALU_jMr = ACC 09 C O p K F | y T ( 7 1 , 

1,1 0 : a'u.ir P a'u.oo 5 src.f rjTe ,j , r.sourc* 7 , 

55a 0 : L 0 A D _l. E M ( f U 9 R F : , T (7)1 KlT,i OFF , 

*1 0 : aest.fr ame 0 , rudest / , r_w 1 1_in 5 , ah.ctrl 1 , 

559 0 : LOAD ( A cruwui.ATi.il? 1 wifn JPD ( lEo I CURRENT c 7 ) ) 1 , 

i«l 0 : a_„ 1 , o_i n 5 , src.f ra*e 0 , r.source 7 , jod.ctrl F , 

540 0 : LDAD.npF ( C u 0 K F ih T 17 1) djT h J»o ( |_EN ( CURRENT 1 7 ) ) 1 , 

M 0 ; aest_freine f , r_H eS t 7 , r_* 1 n_in 5 , src_frame 

M 0 : 0 , r.sourc* 7 , j n o _C f r 1 b , 

541 o : inrvr._r ai l An; y _uTo * uTl_io_aun 

M 0 ! nac i , lit 14 ip * uTd Tij^aD, 

541 0 : ; 

54a o : CI.k. in,v.,,r.3K , 

• o : u»v.c*d 7 1 , 

54 4 u : LDAD_AlM ( Pof , I u 1 1 a 1 7 J ) ,ip J A , j * i r CUFR<PO (7)1, 

-i 0 : oesr.f rare 1 , '•.Cest 7 , r_„ j a _ i n 2 , src_fr a -e 

‘■A 0 : U , r _ s C u r C e 7 , 

545 0 : i p Ao‘ ! . c J_U 1 Ht ■! ''OTi. uf‘!.t c fA 

d 0 : test u , [>r|arit* 0 r> 5 n 1 , 1 , f a Ujn 7tPU 

545 0 : ; 

54 7 0 : LOAD_AUN ( CURRENT (7)1 n'iTN 0 , • 

M 0 : des t _f r ame 0 , r_dest 7 , r_w 1 a.in 0 , 

548 0 : UFF_AL0_0UT = 2FKC OR PREVIOUS ( 7~) , 

M ^ • alu_in ? , rjro 2 alu_oo 5 src.f rsine 3 , r source 7 

549 0 : load ( ACCdMULATuR 1 WITH OFFSET , 

M 0 : a_w l , o_i n j , 

550 0 : RETURN 
M 0 : nac 2 

55u o : ; 

552 0 : UTU_2FRO : 

553 0 : UFF_ALU_UU T = ONE RFV_viTnM 5 COMMON f 0C7I , 3 1 , 

lV| ® • a 1 u. i n P , rand 5 alu_op 1 src_*rame ? , r.source 

'40:5, ccm_e*t £F<ji , 

554 0 : L0 An_OF F ( PRFv'uUb (7)1 t.ITH OFFSET , 

M 0 : dest.frame 3 , r_dest 7 , r_w 1 o.in 3 , 

555 0 : LOAD ( ACCUMULATOR 1 WITH U F F S E T , 

HO: a_w 1 , o_ in 5 , 

55b 0 : L 0 A0_A ON ( PRFvluUS l 7 ) ) u I T H 0 , 

i'l 0 : dest.frame 3 , r.dest 7 , r_w I a in 0 , 

557 o : RETURN 
M 0 : nac 2 
557 0 : ; 
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560 o : ASS0c_l*'l p A_u ft J : 

561 U 5 3F 1 .iAbK , 

-I 0 : aev_c"ii i 3 , 

5 hi u : IHmP ( A Tt|f> ) 1 T n AO:. ( C « • rl "» fc ^ T l 1 ) ) , 

m 0 : a_w 1 , o.in c » src.frane 0 » r.sourjf 1 # 

S 63 U : LCIING.CaLL «Oi,_:,T 0 * A Or, _ f P_U i D 

M 0 : nac 7 » I ' t 1 4 4vjo_'ur' * a u H _Tu_U T u 

563 0 : ; 

565 0 : C.lh_f-:nN_-i4oK - 

m u : dev.cr’U 7 7 , 

56o 0 : uFF.AL U.U'J I = /PHD 06 CURRENT ( 7 j , 

M 0 : alu.in ? , ran , 3 2 alu.oc 5 src./rame 0 , r.source 7 , 

56 / y : lOaQ.FiFF ( CUPRFijT ( i ) ) nir uFFSeT , 

M U : aKSt.f rflffi* n , r.deS t 5 , r _w t n_in J , 

568 0 : lOaO.AL'N ( CuOfFKT ( 7 ) ) UlTn 0 

MO: gest.^ra** 0 , r.rtest 3 , r_* i a.in 0 

568 0 : ; 

570 U : OFF.ALU.UU f = ZFRf! OK CURP£f T ( 6 ) , 

MO: al u_i n ? , pjnij c alu.rc 5 ?rc_lra»a 6 » r.source 6 , 

571 y : L OA0_opp ( CuOKF.'.T ( a )~) "UTh jef5 c T , 

MO: oest./ratne 0 , r.dest 4 , r_w 1 o.in 3 > 

5 72 u : LOAO_»GV f r UPn c uT (Mil *1 Tn T , 

0 : de s t _ f r » t e o , r_H e st a* , r_» 1 i.in u , 

5 7 j 0 : LONR_R07u ‘•5 o0l_S f A»CH 

Mi 0 : n a c 6 i I i t 1 4 0 s S o C _ S r_ a n C u 

5 7 i o : ; 

57o 0 : AS 8 n C_uT !) : 

57/ U : RFA9 Tu COK = t v f_i oSl ,J b JFF.AI U C n -J _L F NG I H ( 16 ) 

57/ 0 : FTu ( n 1 u H i , a c « < 1 l 

M 0 : m*T 1 T/i 11 -jr .Ctrl i !er.Ct p l 5 rand A 

575 0 : J F F _AL U.U 1 1 T = UMij t 16 1 PLUS CURRENT C t ) 

M y : alu.i" 3,10, Hri 6 16 alu.or 3 src_f rare 0 , r.source 1 

578 u : ; 

5 fl 0 0 : «FAO TO CUKP£N1_4 LiFiNG 0 FF_AIU , CUN.LEnGTH c 32 ) , 

M 0 : mrrr 1 nH 1/ aF.Ct r I 1 , leo.rtrl 6 , 

S«1 0 : UFF.Al U_U"T s i_ T I I fc> ( i? 1 PLII 8 CUnRtMT ( l ) 

MO: al u.i n 7 , 10 , liriK 32 alu.oo 7 src_franne 0 , r.source 1 

5«1 0 : i 

583 0 : HEAD ru CURREM.5 USING uFF.aLu CCihl.LENGTH ( 32 ) , 

M 0 : in err 1 I'd 1 3 dK.Ctrl 1 leo.Ctrl 6 , 

5«4 0 : i)FF_ALU_ 0 "r = LIII 6 ( o« 1 plus CURPENI ( l ) 

m 0 : a'u.ir 3 , 10 , titiK 64 alu.oo 3 src.frare 0 , r.source 1 

564 0 : ; 

587 0 : ASSOC..SFAPCH : 

50 1 o : OFF.ALU.ul'l = L T 1 1 6 C 544 J UR CU M M0I| ( a)P,0 , U ) , 

MO: al u.i n 7 , l 0 , litl 6 544 alu.oo 5 src.f rare 

Mi 0 : 2 , r.source 0 , co*.e«t Sofl , 

552 0 : LOAO.OFF f CURRENT (71) wi Th uF F S£ T 
m 0 : aest.f ra«ie 0 , r.rlest 7 , r_>u l o.in 3 

592 o : ; 

594 0 : LOAO.AUN ( CURRENT ( 7 ) ) WITH AON ( COMMUN ( ? , 5 ) ) , 

M 0 : aest./raeie 0 , r.dest 7 , r_<. 1 e.in 2 , src.f rare 

M 0 : 2 , r.source 3 , cor.eU ? , 

5°5 0 : LONC.CALL PTK.rO.OcSL 

M 0 : nac 7 , Iitl 4 PTR.TO.UFsC 

595 0 : ; 

5° 7 0 : LOun.CAlL Aar.LOOxuP * A A T.LUOk, up 

M 0 : nac 7 , I it 1 4 AA t _LU0kUP * AAf.LOUMUP 

5°/ 0 : ; 

599 0 : WITH CURRENT ( 7 ) , 

* 0 : src./raoie 0 , r.sourre 7 > 

600 0 : IF LtN.Hc.O rHfl C-OTU FO JMij.L' 1 1 9 Y 

M 0 : test F , pr I a r t t v 0 nac 4 , I 1 to FUUNO.ENTRY 

600 0 : ; 

6 0 u 0 : OFF _AL U.LjU T = 8 T A SE O.l t MU Th in.i_i.FnG TM ( 72 ) RFV.MJTmUS 

604 0 : CUKRcur ( i ) , 

m 0 : a'u.in 1 len.ctrl 6 alu.on 1 src.fratre 0 , r.source 1 , 

005 0 : l n a n _(i F f ( current ( i 1 i with offset , 

M 0 : aest.frarre 0 , r_,-t e st 7 , r_„ 1 n.in 3 , 

60b 0 : L 0 AD_A UN ( C URkB’ N T ( 7 ) ) 41 Tn All.N ( CURRENT ( 1 ) ) , 

M 0 : oest.trar* 0 , r.4 e st / , r_« 1 »_'n 2 , src.frarre 

40:0, r.source 1 , 
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bO 7 0 
M 0 
60 7 0 

o 09 o 

b09 0 
-1 0 
•i 0 
M 0 
b09 0 
b 0 9 0 
,9 0 
M 0 
M 0 
b09 0 
M 0 
b 99 0 
b 0 9 0 
,-1 0 
M 0 
M 0 
b 09 0 
6 0 9 0 
M 0 
M 0 

(■1 (j 

6 0 9 U 
609 0 
611 0 
M 0 
bt2 0 
M 0 
612 0 

614 0 

615 0 
615 0 

14 0 
M 0 
M 0 
615 0 
615 0 

M 0 
M 0 

615 0 

M 0 

616 0 
M 0 

616 0 
616 0 



LOijR_C#Ll S'ipPuOr * savF_4|_C_^ 0_T,4 
nac 7 > Ht19 1 * 5AVt_i.rL_“'Ji)_r9 

t 

INu TV! STlU.E , uFF.ALt.lM'l = t'llb ( ,a«l?C.9 ) Or COMMON 

( u , 2 ) , LOaO.^ff f r,j*.'v,n , ( ,i , i ) ) 

rand 15 , a 1 j_in j , I 0 , I'tlo o012Ln> alu.op 
5 srr_ # ram= ? , r _ s o u r c * i , c o n.e * t 4 , Hest_f rjire 
i < r.oesf 3 . ro”>_»*7 0 , r_w 1 o.l" 

«i rn nFFs c r , l^aoj. £'••■ ( roM~o,. i s ) ) with 

literal t coy.LEoG th f r ) i , Li.aj.aon t commun ( o , 7 
3 i .d«st_f rame ? . p^^est i , c ">m.e * t 0 , r_« 1 
'.in i » len.ctrl 0 dest.frame 2 , r.des t 

i > cou.ent 0 , r_w 1 a.in 
WITH 0 
0 

? INDIVISIBLE , OFF.ALO.OUT = BIASED .LENGTH CON.LENGTH 
( 0 ) CM? C LM?HF N T ( 7 1 LOAO.OFF ( COMMON (0,4)1 
} rand 15 , alu.in 1 len.ctrl 0 alu.op 5 

src.frame 0 , r.source 7 dest.frame 2 , r_dest 4 
, com_e*t 0 , r.w 1 o_in 

«ITH OF F sF I , LOAD.AOn” f COMMON (0,4)) WITH 
AON ( CURRENT ( 7 ) ) LONG.CALL I NVOKE.S IGNALLE * 

3 , oesr_*rame 2 , r.dest 4 , com.ext 0 , r.w 1 

a.in 2 , src.frame 0 , r.source 7 nac 7 , 1itl4 
ThVUKE.STSNALLE * 
iMVOKF_SlG.\ALLt 

f 

LOAD.AON ( CURRENT (71) WITh 0 , 
dest.frame 0 , r.dest ? , r_« 1 a in 0 , 

LONG .GOTO HE TMHN.FR0M.3IG 

nac 6 , 1 i t 1 4 RE TUPN.FRUM.S 10 

i 

found.enipt : 

OFF.ALU.ULir s 2EHP OP CURPENT ( 7 ) , LOAD.AON ( 

PPtVIOUS (71) KITH AON ( CMPO E N f ( 7 ) ) 

alu.in ? , ra n d 2 alu.op 5 src.frame 0 , r. source 
7 , dest.frame 3 , r.dest 7 , r_w 1 a.in 2 , 
src. frame 0 , r.source 7 

, LOAD.LEN ( PREVIOUS ( 7 ) ) WITH LEN ( CURRFNT 
( 7 ) ) , loao.off f previous < 7 j ) with 
, dest.frame 3 , r.dest 7 , r.w 1 I _i n 2 , src. frame 
0 , r.srgrcr 7 , dest.frame 3 , r.dest 7 , r.w 1 o in 

OFFSET , 

3 , 

long.guto P T P_ro_ntsc 

nac 6 , I i t 1 4 °TP_Tu_uF3C 



) 



COMPILA I ION CUMPLETt. <u STaTe M£«j f 5 PROCFSSEO 



DATA GENERAL F H P - FETCH MICROCODE GENERATOR, REV. 6.0 (3/16/79) 
6/25/61 AT 2 : 45 : l u 

(NPUT FILE: OFSC_Td_PTR 

OBJECT FILE; OFSC.Ty.PTR .u« 



line 


NC 


.SOURCE 






1 


0 


tNO 


LIST 






167 


0 


*L 1ST 






166 


0 


/M.Mlilit.ittMOIIlllHMMIIIIIMttHllilllltlllHlHttttH/ 


169 


0 


/ * 


0ESC.I0.PT9 / 0E Sc.l O.UiO.P T9 




* / 


170 


0 


/ * 






»/ 


171 


0 


/ » 


WRITE CURRENT ( 7 ) AT CURRENT (6) 




*/ 


172 


0 


/* 






» / 


173 


0 


/* 


T h ia CALLE0 S'JfaOOUi INF ta^es a desrciptor 


n a 


*/ 


174 


0 


/* 


callers reaister fr a me jnj converts it to a 


Pointer 


A/ 


175 


0 


/* 


wnicH it places in memory. 




*/ 


17b 


0 


/* 






*/ 


177 


0 


/* 


Tne memory location at which the pointer is 


wri t ten 


*/ 
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178 

179 
1*0 
181 
188 
183 

18(J 

185 

l B P 

187 

188 

189 

190 
1°1 

198 
193 

19(4 

19*3 

1°6 

197 

1 98 

199 

2 0 0 
801 
808 
803 
809 

805 

806 
807 
806 

809 

810 
811 
818 
813 
219 

215 
1 16 

1 1 7 

216 
819 
8?0 
881 
888 

883 

884 
825 
82b 
227 
226 

229 

230 

231 

238 
833 

234 

235 

236 

237 
236 

239 

2 4 0 
241 

842 

843 

24(4 
24 5 
24 o 
24/ 
246 
849 
250 
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0 : /* 
0 : / * 
0 : /* 
0 : /* 
0 : /* 
0 : /* 
o : /* 
0 : / » 
0 : /* 
0 : / » 
0 : /* 
0 : / * 
u : / * 



is qiven in another users reoister as a riescriDtor. */ 
Tf th e AON of the destination is the same as that */ 
of the oointrr, an intra object Pointer is created, */ 
otherwise a UI0 or NULL Pointer is created. */ 

*/ 

Dd SC_T 0_tJ 1 0_P|P will always write a UlD pointer. */ 

*/ 

* / 

T nPUT : Ihe address of fne beoinnina of a pointer in »/ 
c a 1 lers CURRENT Cb) . »/ 

A oescripfor to qe made into a pointer arid »/ 

written a r the aqove aadress in CURRENT!?). */ 

*/ 



0 


/ * 


output; uuNt 






A / 


0 


/* 








*/ 


0 


/* 


NQTfc.: ACC is nof save 1 " 4 


or restored 


* / 


0 


/» 








*/ 


0 


/ * 






G.D. 


P/17/80 */ 


0 


/ * 


Converted to new pointer 


formats 


^ « 0 . 


1/09/81 */ 


0 


/ * 








*/ 


0 


/ ft * A ft 


ftftft*ft**ft***ftft***ft*ft*ft*A*A 




o c 




macro Td“P 


M t 1 NS 


CURRF NT ( 0 ) 


ENDMACT 


0 




MACRO u X 0_ 1 6 . .4 7 


M£ A flS 


CURRFnT_6 


FNOMAC 


0 




macho u i r . i tj. . u 7 


*'t AuS 


CURRENT ( 6 J 


ENDMAC 


0 

u 




MACHO «ot_aodh 


M£ANS 


CURRENT ( 1 1 


FNOMAC 


0 

0 


FnTkY 


otSL_ro_p i r • 








0 




Tn01V1S1«lF, 








0 




OFF_AlU_OUT = 0 I a 6EU_LFdO fP Cun 


_LENGThT0) or 


PRt V I PUS l 7 ) 


0 




SUUHCt (0FF_«LU_OATA) 


To JPD_6lJS(DATA_THAP) , 





0 : L U A U_U F F UE M F) with An i; (p°tviouS<7n , 

0 : LU*0_ao h (T£Mh) IV I T In A OM ( POd V [ OUS ( 7 ) ) , 

u : TP 0 F F _ S T gN_F t,_ 0 IHEU C-u T 0 U c F_tlK; 



0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

u 

0 

0 

0 

0 

u 

0 

u 

0 

0 



T N n 1 V 1 9 1 a L E » 

OFF_ALIl_9UT = LIT 3 2 ( T 7 F p F F B f F ni ) AND PRFVIOUSm, 
LOAD (ACCUMULATOR J wTTH OFFSET; 

IND1V1SI9LF, 

nFF_AL'i_nuT = ACC Oft C0N_0 , 

SjUdrd TnFF_ALU_OATA> T(j JPD.riUS ( D A T 4_TR AP ) ; 



0FF_0K: 

T NO 1 V I 8 L 9Lf , 

LuAD ( ACCoMJL aToP ) w T T u AUN (PREVIOUS ( 61 ) f 
TNDIV1SI5LF, 

OFF _A LU_ n U T = ACC *uR TEMP, 

L0AD_A0,m (T£Mp) with OFFSET, 

TF AON_EO_0 THFN GOTO muLL_PTR; 

IND1 V1S19LF , 

WITH TF,V|P, 

LU»D_A0N (Tt M P) WITH (I, 

TF AO,\,_NE_0 THFN GOTO Dt SC_T0 _H 1 0_P TR ; 

WHITE FROM 0A1A_THAP USING DESCRIPTOR PREVI0USC61, 

p E TuPn, C0N_LENGTHC32) 



ENTRY ndSL_IO_l'10_P|P; 

OFF_A L ll_-|UT = LiT32lS>cO000O0n„>) OH PPEVI0USC7), 

LOAD.OF? (T£MP) WITH U F F T , 

LUA,j_AON (TEMP) '*J l T t1 \j’. 

OFF_ALU_OUT = 7t 9iJ 0° Tt«P, 

SOUlnC t ( U F F_AL U_l> A I A ) in ..IPO_OuS(nATA_fPAP) ; 

WhTTF F r O i-i j A T A Trap IjSI'-'G DESCRIPTOR PREVIOUSfb), 

CON_LENGTH(3?) 
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25 1 0 
2^2 0 

253 0 

254 0 

255 0 

25 b 0 
257 u 
25b 0 
25-5 0 

26 4 0 

26 1 <j 
262 0 
26 5 0 
264 0 
263 0 

2 6o 0 
2b7 0 
268 0 
26V 0 

270 0 

271 0 

272 0 

273 0 

274 0 

275 0 
27b 0 

277 0 

278 0 

279 0 

280 0 
2 fl 1 o 
282 0 

283 0 

284 0 

285 0 

28b 0 

28 7 0 
288 0 

289 0 

290 0 

291 0 

292 0 

293 0 

294 U 

295 0 
2°b o 

297 o 

298 0 

299 u 

300 0 

301 o 

302 0 
30 3 0 

304 0 

305 0 

306 0 

30 7 0 

308 0 

309 0 
510 0 

311 0 

312 0 

313 U 
514 0 
315 0 
31b 0 

31 7 0 
318 0 

314 0 
320 0 



L U A L) (ACCLI'AULATUR) aTIH A 0" ( PRF U T QU3 ( / 1) 7 

/« A 9 1 5 i s ,>5b b’ts -m 1 He . ACC contains t^e A 015. */ 

l.vOl VI818L8 , 

068_AUU_OUT = A l f ItF f_OHIF rPO(2) A MO C 0N_F F F F , 

L'jAu> ( ACCUMULATE ) .ilfH AfFjFr; 



/ * 4*^4 : i 1 0 10: 131 * / 

I 1 n 1 V 1 8 1 9 L F , 

3 tVi.t M ' 19 AcCu«‘JL AToF i'SIjG n f f _ ai_i 1 r ijm _1 t m li Tn f 3 2 ) , 
n 6 F _A l ■' .9 J T = ACT L t F T _3H 1 F | Fu ( b 1 PL'*3 A 0 T _P T R , 
luAj_ati-j (6jT_A u 6k) -:jT|, ;,0 , ( AO r_PT rt ) , 

L u '' yJJ if lAut_Aun«) :-i 1 T t . jP F T ; 



/* -t ° a u ■ 1 i -n 1 1 6 : 4 7 1 * / 

T a O I V J , 

PtAu.PHr in 1 1 1 6 _ I b . . 9 7 USING OF F _AL U C 0N_L E NG T H ( 32 ) , 

OFF _AL U_nuT = LIT16(321 pl"S AOT.ADOR; 

/* Pass 111010:151 to L- A r a TRAP */ 

InO I VISIBLE, 

OF F_A L U_nuT = Atr AMD CU'5_FFFF, 

50* IRC E (OFF_ALU_0ATA ) Tu JPD_BUS ( DA T A_TR AP ) J 

/* Read UlTU4a:7 Q J */ 

INDIVISIBLE. 

PEAO.PHt 10 ACCU'AuLATuR USING OFF.AlU CON_LENGTHC32) . 
OFF_ALU_nuT = 11616(641 PLUS AOT.ADOR, 

I.UAQ.AON (AL)T_Ai;ORl WITli 0* 

/* write (J T D 1 0 : 1 5 1 * / 

WRHF From 0ATA_TRAP USING 0FF_ALU WITH PREVIOUSfb), 
OFF_ALU_OUT = L1T16C321 ra LH5 PREV10US(6), CON_LENGTh ( 3? ) 

L'JAu.OFF (TEMP) W[Th uFFSET, 

L ij A 0 _AOu (TE m P) with AO(M(pP£VI0US(6n ; 

0FF_ALU_0UT = 7tPiJ OR U10.16..47, 

source ioff_alu_oata i iu jpo_8U3(Oa i a.trapi ; 

/* Arit» U T D ( 1 6 • 4 7 1 * / 

W R T ( E From 0 A 1 A . T R A P USING uFF_ALU WITH PREVTOUS(b) , 
OrF.ALM.nuT = t 1116(641 PL"S P9EV10U?(6), CON_LENGTH ( 32) 

I. UAu_lFF (Tl w H) X i Tit l.‘F F St T , 

LuSj.aO,, (Tt'V) KJTri a 0* ( pP t V I OUS ( 6 ) ) i 

OFF _AL U_OU T = «cc OR LO i_0 , 

SuUr.CE t OF c _A L 1 1_0 A T 4 ) t f f jPu_dUS(D» TA_TRAP) f 



/* I. rite uTU( 48 ; 74 l */ 

“•rt if Fi.’Oh L'Ata_t><a? usru, off_alu .v i r H T t MR , 

OFF_A L I.I_OUT = Hi A 0 FL>_L C N r . IH P LUS TFMP, 6 ON_L E m GTH(32) 

I.UAG_AO,i ( T L H p ) "j j tu ^ , 

9 E T u 9 N f 



uul l_ptr : 

TivO I VISIBLE, 

LOAu_AOg (TE m P) 'a 1 1 T ri (1, 

OFF_A L U_OuT = ZtPUS, 

S'jnRFE (OFF _A LU_n« T 4 1 T„ J PO_ 8 'JS ( 0 A T A_T R A p ) ; 

••'KrfF FhOt l )ATA_TrAP using UF 8 _ALU WITH PRFVTUUS(b), 
9FF_AL"_0UT =■ PI A jF,', .LENGTH Pl"S PRtVIDUS( 6 ), nuN_L£HG TH ( 32 ) 

R * T T E From .j t i a.Th a F using uFF.ALU with PRFVIUl'Sfbl , 

n F f _al u_ou t = I. iri6(R4' Plus ppeviouS(M, cun_i engTh ( 32 ) 

' R r I F From yAM.TRAP uSl'U, U C F_ALU wIlH °RFVTOU3(b), 

°ff_olu_out 7 urib(Ob) °l '5 pRtvinus(6), c u m_l ength( 32) 
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i?t o 

122 a 

123 o 
I 2 y o 



WR [ I E FROM OFF.AIU.jATA USTNG DESCRIPTOR PRE V 1 OUS ( f> ) , 

0 F F _alU_OUT = ONES# CQN_LENGTH(32) . 

RETURN ; 



IPUT FILE: ? 1 3 . 1 _P ILF 1 * 

UEfT FILE: DFSC.TCI.PTR.OB 



Mt N ; SOURCE 

30b 0 : ENTRY DESC_TO_PTH : 

30 7 0 : I NOT VI SI RLE / 

M 0 : rand 15 , 

J 0 13 0 : OFF_AL U L) 1 1 f = 6 1 ASED.LENG Th L0N_LENGTH C 0 I OR PREVIOUS ( 7 ) , 

H 0 : a 1 u.i n 1 len.ctrl 0 a'u.oP S src.fraue 3 , r.sourc* 7 , 

209 o : SOURCE c OFF_ALU_DATA ) 10 JPD.6US ( OATa.IRAP 1 , 

M 0 : j od_c t r 1 7 dev_c«a 26 , 

210 0 : LOaO.OFF ( CURRENT (0)1 WITH AOn ( PREVIOUS ( 7 ) ) , 

M 0 : dest.f rame 0 , r_dest 0 , r_w I o.in 2 , src.frafe 

M 0 : 3 * r.source 7 , 

211 0 ; L0A0_A0N ( CURRENT (0)1 WITH AON ( PREVIOUS ( 7 ) ) » 

m 0 : dest.frame 0 , r.dest 0 , r.w 1 a.in 2 , src.frame 

M 0 : 3 » r.sourcs 7 , 

212 U : IF OFF.SIGN.EQ_0 then GOTO OFF_OK 

M o : test 3 , polarity 0 oac a , 1it8 0FF_0K 
212 0 : ; 

214 0 : INDIVISIBLE , 

N 0 : rand 15 , 

2 1 5 0 : QFFJU.U.OUT = LIT32 ( o)7FFFFFFF3 ) And PREVIOUS ( 7 ) , 

M 0 : aUi.in 3,11, 1 i t 52 H7FFFFFFFo) alu_op 6 src.frame 

H 0 : 3 i r.source 7 , 

21b 0 : LOAD ( ACCUMULATOR ) WITH OFFSET 
M 0 : a.w 1 , o_in 3 
2 1 o 0 : ; 

2ia o : indivisible , 

i«l 0 : ranrl 15 < 

219 0 : OFF_ALU_UUT = ACC UR COMMON l nH3<v , 0 ) , 

M 0 : a lu_in 2 a'u_OD 5 src.frame 2 , r.source 0 , com.ext SBt) , 

220 0 : SOURCE ( OF F_AUJ_0 A T A ) TO JPQ_6US ( OATA_TRAP ) 

M 0 : j po_c t r 1 7 deu.cma 28 

220 o : ; 

222 0 : OFF _0 k : 

223 0 : INDIVtSieLE , 

HQ: rand 15 , 

22M 0 : LOAD < ACCUMULATOR ) WITH AOim ( PREVIOUS ( b ) ) 

M o : a_w 1 , 0 _in 2 , src.frane 3 , r.source 6 

22U o : ; 

22b 0 : INDIVISIBLE , 

N 0 : rsnd 15 , 

227 0 : OF F_ALU_UU I = ACC XOR CURRENT ( 0 ) , 

M 0 : gTu_i n ? a 1 u.oo U src.frame U , r.source 0 , 

226 0 : LOAD.AON f CURRENT (01) WITH OFFSET , 

MO: aest.fram® 1 r r_des t 0 , r_i™ 1 a.i n 3 , 

229 0 : IF AQN.EU.U THEN GOTO nULL.PTR 

M 0 : test 4 , polarity 0 p ac 4 , litS NUU — PTR 

229 0 : ; 

231 0 : INDIVISIdLt , 

M 0 : rand 15 > 

232 0 : WITH CURRENT ( 0 ) , 

MO: src.irame 0 , resource I) _, 

233 0 : LOAD.AUN ( CURRENT ( 0 ) ) WITH 0 , 

H 0 : dest.frame 0 , r_Hest 0 , r_* 1 a_in 0 , 

234 0 : IF A 0 N _M t _ 0 THEN GUTU UF3C_Tu.UTD.PTR 

;-1 o : test 4 , polarity 1 n <ac 4 , 1it3 DESC.TO.U ID.P TR 

234 0 : ; , , . 

23b 0 : WRITE FRu*x OaTA.IRAR USING DESCRIPTOR PREVIOUS ( 6 ) , 

M 0 : mem 4 jDO.ctr' 4 db.ctrl 0 src.frame 3 , r.source 6 , 

237 0 : RFT"R\' , CON.LtNGTii ( 32 ) 

MO : nac 2 , len.ctrl & 

237 o : ; 

241 o : ENTRY uFSC.Tu.UIU.PTR : 

2«2 0 : O p F ALU U" I = t_TT32 ( ai p »)0 00 000 R ) OR PREVIOUS ( 7 ) , 

1*1 0 : aTu.in 3,11, litiR MbOQOOOOOu alu.op S src.frame 
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A 0 : 3 , r.snjrcK 7 , 

2 a 3 o : Lrur>_nfe r current ( o t ) with offset , 

MU: ae S t _ * r erne 0 , r_dest U , r_* 1 n_in 3 . 

24a o : loao_aon r CuRRFnt ( n ) i wiTn o 

il 0 : apsf.frane n , r_dest U , r_w l a_in 0 

2 a 4 o : ; 

2ao U : 'JFF_ALU_GUT = ZERO OR CURRENT ( U ) , 

M 0 : alu_in ? , rand 2 alu_oo 5 src_7rame 0 , r.souree U , 

2 « 7 0 : SOuRCE < opF_AcU_PATA ) TO ,JpO_*JS < OATA_TRAR ) 

M 0 : jod_Ctrl 7 <Jnv_C"'d2A 

2 a 7 u : ; 

2a V 0 : ..RITE F°U'-‘ OaTa_TRAP iisthC- nESc Q l°TOK PREVIOUS (61, 

MO: mem a jod_ctrl a dc_ctrl a src_frame 3 » resource 6 , 

250 0 : C'V.LENGIw ( 32 j 

M 0 : I en_c t r 1 6 

2 S 0 o : ; 

252 0 : LOAO ( ACT JMUt.ATi.iR 1 dITh AO i ( PREVIOUS (71) 

M 0 : a_w 1 , o_in 2 , src.frare i , r_snurce 7 

2S2 0 : ; 

255 0 : IMuivTSIp.Lt . 

M 0 : rand 15 , 

2^6 0 : OFf_AUI_Ull ! = ACC cFF T_Sm I FTfcO ( ? ) Arjf) COMMON ( o)C<v , 6 ) , 

MO: a'u_in ? s * R alu_on 6 src_fra«ne 2 , r.souree 

M 0 : a , com_e*t ul Cs , 

257 0 : LOAD ( ACCUMULATOR ) WITH jFPStT 
M 0 : a_w 1 , o_in 3 
257 0 : ; 

260 0 : IMuTVTSTdLE , 

M 0 : rand 15 , 

261 u : kEaO.phv To accumulator uS[M(, uff_aIU lOn_lENCTH ( 32 ) , 

MO: mam 5 md 1 dp_Ctrl I lan_ctrl 6 , 

262 0 : UFF_ALU_Ulll = 4CC _ LEF T_°m I F TEO ( 6 1 PLUS COMMON ( a , a ) , 

MO: a'u.m ? s* 6 j'u_on 3 sre.f rj*e 2 , resource a , com_»xt a , 

263 0 : CO A 0 _ A uU 1 CU°kFi;T rill n|In A n.j ( common ( a , a 1 l , 

M 0 : jest.f r?me 0 , r.Hest 1 , r_> ) a_in 2 , sre.f rame 

M 0 : 2 , r_srur;p <1 , ;a».e»t 'J , 

260 0 : lOaO.off r ruRKR.iT ( i i 1 -• i t,, j c f s t T 

M o : .lest.iraTe n , r_da«t l . r_* l o.in 3 

26a j : ; 

26 7_ 0_: I Mu T v T 5 T u .l. c , 

M 0 : rand 15 , 

266 0 : REAO_PrlY Ty CURREM|_ 0 USING UFF.ALU CON.LE.vGTH C 32 ) , 

M o : mem 3 md ta Oh_ctr| I 'en_ctrl <j , 

269 0 : UFF.ALU.U'IT : LII16 ( 3? ) PC'S CURRENT ( 1 ) 

M 0 : alu_in 3 , l 0 , litlR 32 3 lu_oo 3 src.fr»»e 0 , r.souree I 

26R o : ; 

272 0 : INulVIsroLE , 

M 0 : rand 15, 

273 0 : 0FF_ALU_U"T = ACC A NO COmMuN ( ^C^ , 6 ) , 

M 0 : alu.in 2 a 1 u.oo 6 src.frane 2 , r.souree 6 , com_exf e>C , 

274 0 : SOURCF ( OF F _ A L U_0 a T A ) TO FPDJ30S C 0 A T a_ [ PAP 1 

M 0 : jcd_ctrl 7 dew c*o 2° 

274 0 : ; 

277 0 : I no I V T 3 1 dl t , 

M 0 : rand 15 , 

276 0 : READ_PhY TO ACCUMULATOR USING OFF.ALU CON.CENGTH ( 32 ) , 

M o : mem i md 1 do_cTr1 * len_cTrl 6 , 

279 0 : UFF_ALU_OUr s LIT lb ( 64 1 °LUS CURRENT ( 1 ) , 

M o : a'u_in 3 , 1 0 , 1 i t 16 64 alu_oo 3 src_frame 0 , r.souree 1 , 

260 0 : LOAO_aun ( CURRENT ( 1 1 1 with o 

M 0 : vlest_ # rame o , r_d e ?t 1 , r„e l a.in 0 

2 H 0 0 : ; 

2A 3 0 : v ( Rirt rRuM OaTa_|RaP USTiwG o F F _ Act i with previous ( 6 ) , 

M 0 : men; A jou.ctrl a dt-,_ctrl 1 src.frame 3 , r.souree 6 , 

2°4 0 : OFF_ALU_uUf = t. T T 1 a 1 3? ? °LHS PREVIOUS ( 6 ) , 

244 o : CON_LE;wC,[H ( 3c ) , 

M 0 : alu.in 3,10, 1 i t i f> 32 a'u_oo T sre.f ra*e 

M 0 : 3 , r.souree 6 , len.cfrl 6 , 

2»S o : lOao_ofp r current < n ) 1 with jpfslt , 

i-t 0 : dest.lreme 0 , r_dest 0 , r_w 1 n.in 3 , 

2*0 0 : loao_Aun ( CuRRf't (nil wjTh m" ( poevious (6)1 

M o : riest.irame n , r_dest o , r_w l a_>n 2 , sre.f ra*e 

M 0 : 3 , r.souree 6 ‘ 
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28o o 
2«a u 

,'l u 
2*9 0 
M 0 

2*9 o 

292 l) 

i9 0 

293 0 
2«3 U 

M o 

M 0 
299 U 
M 0 
293 ,j 
<4 0 
M 0 

2RS o 
<>97 o 

M 0 
29(3 0 
M 0 

29a o 

301 0 
M U 

302 0 

302 0 
M 0 

303 0 
H U 

399 0 
M 0 
309 0 
30 7 0 

39 a o 

M y 

309 u 
A 0 

310 0 
M 0 

311 0 
M 0 

311 0 
313 0 
M (J 
319 0 
M 0 
319 0 

316 U 
M 0 

317 0 
M 0 
M 0 

317 0 
319 0 
M 0 

3?0 0 
M 0 
M 0 
32 0 0 

322 0 

M 0 

323 0 
M 0 

329 0 
A 0 
329 0 
329 0 



/ 

U C F_AI.U_UH1 = ZFri'9 09 C'l.99 t Nl t 6 ) , 

alu.in 2 , raou 2 alu _cu 3 src.frame 0 , r.source b , 

SnuRLF ( ofp.alU.Data J TO jpr>_0'j9 ( OATA.TRAP ) 
jnd.c'rl 7 dfv.c'd - 

,v 9 1 r t F Pu M 09TA_r9A o Ub T “JG n F F _ ft i_ I ) WITH RRtVlOUS c 6 ) , 

mem 9 joa_ctrl H do_ctH 1 sre.Creme 3 < r.source 6 , 

UEF.AlU.UUT : LTHo ( o« 1 PLUS PREVIOUS 16), 

LON~lF .'<0- 1“ • 32 ) , 

a 1 u_ i n 3 , 1 n , Ittlb 69 atu.oo 3 src.f ' , a«e 

3 , resource 6 , len_c f rl 6 , 

L OA0_OFF r ruPrfFf.T (01) WITH ijFpFtT , 
dest.trame 0 , r_He*t 0 , r_* 1 o_in 3 » 

L 0 A 0 ~ A l, ' 1 ( F'JPRP~T (01) 'J I T H \Oj ( PREVIOUS ( 6 ) ) 

o« s r r ame o , r_deSt 0 , r 1 »_in 2 , SPC.f ra*e 

3 , r.sourcp 6 
# 

UFF.ALU.uUI = xCC i|9 CU'b-’P m ( i 9.1 . J ) , 

al u_i p 2 alu.or S src.^a"? 2 , r.source 0 , co*.««f 9o9 » 

source ( off_alu_oata ) ro JPO.BuS ( OATA.IRAP ) 
joa_ctrl 7 d'v.cid 2 s 

wR I Tt F D 0 M DaTa.TPaP USING OFE.ALU WITH CURRENT 10), 
mem 9 j od.c t r I 9 db.ctrl 1 spc.fpame 0 , r.source 0 , 

uFP_ALU_uUT _ = rtt ASEO.LENGT h PLUS CURRENT C 0 ) , 

CON J-FNGTH C 32 j , 

a 1 u_i n 1 a 1 u.oo 3 s re. 1 r ame 0 , r.sourca 0 , len.ctrl 6 , 

l oao_«uN { CURRENT ( 0 ) ) with 0 , 

des t r ame 0 , r _ a e s t 0 , r _w 1 a _ I n 0 , 

RETURN 
nac 2 

f 

NMLL.ptR : 

I N u I V T 3 T a l t , 

rand IS « 

LOaO_Au>! f CURRENT CO)) WITH 0 , 
uest.^rame 0 , r_dest 0 , r.w 1 a.i n 0 , 

0 P F _A L U_uUT = ZEROS , 

a 1 u.oo o , 

SOuRCF ( OFF _AlU_0 A T A ) TO JP0.BUS C DATA.TRAP ) 

jDQ.ctrl 7 dev.cmd 2 B 

WRITE F R U W PATA_T9AP MSTnG OFF_A(_U WITH PREVIOUS ( 6 ) » 
mem 9 joa.c t r 1 9 db.ctrl 1 srcjreme 3 , r.source 6 , 

UFF_ALU_UUT~S al ASEO_LENG TH PLUS PREVIOUS l b ) , CON.LENG 1 H ( 32 ) 
alu.in 1 alu.oP 3 src.fra*e 3 , r.source 6 , len.ctrl 6 

*|R I Tt FP0“ OATA.TRAP US TNG OF p _*LU WITH PREVIOUS ( 6 ) , 
mem 9 j dJ.c t r 1 9 Hb ctrl 1 src.frame 3 , r.source b , 

UFF.ALU.UUT = L T 1 1 b ( b9 ) PLUS PREVIOUS ( 6 ) , CON.LENliTH C 32 ) 
alu.iri 3 , 10 , litlb 69 alu.oo 3 src.frane 
3 , r.source 6 , len.ctrl 6 

WRITE FRU M 0ATA_1RA° USING OFF.Al" WITm PREVIOUS ( 6 ) , 
mem 9 jod Ctrl 9 db_ctrl 1 srC_*ran»e 3 , r.source 6 , 

UFF_ALU_0'H~= LUlb t 96 ) °LUS PREVIOUS ( 6 ) » CUN_L£NGTH C 32 ) 
alu.in 3,10, lit!6 9o alu.Oo 3 src.fraee 
3 , r.source 6 , len.ctrl b 

WRITE FRQ M 0FF_ALU_0ATA USING UFaCRTPTOR PREVIOUS ( 6 ) , 
mem 9 j od.c t r 1 7 db_cti"l 0 src.fra#e 3 , r.source 6 , 

OFF.ALU.O'IT = UNtS , CON.LENUTH C 32 ) , 
alu.oP 7 , ien.ctrl 6 , 

RETURN 
nac 2 



'OMPTLATTUN CU^PLcTE, 2o 3TiTE -1 t' | [S “ROcESSEO 




